On Monday, Aug 25, 2003, at 11:12 Europe/Rome, Christian Haul wrote:


On 17.Aug.2003 -- 07:00 PM, Stefano Mazzocchi wrote:

Issues that were still unsolved




1) block identification

All blocks (behaviors and implementations) are identified by a URI. the
format of the URI is as follows:


cob:organization/name/x.y(.z)

If we would identify a block by an XML document instead of a URI, we could list features of a block. Version numbers are a very poor tool to match requirements and capabilities.

nonono, you are making the usual URL vs URI mistake: we want to *identify* a block (either its implementation or its behavior). The location service (that is also, metadata discovery about that block) is an entirely separate issue and *MUST* remain the same in order to allow a high level of decoupling between a resource and the actual location of where those resources are.


This is a critical issue in the semantic web and, IMO, the use of http:// for URI has been a mistake since day one since it leads people to think that URI are URL, while, in fact, they are not and not even meant to be.

Then we could solve

2) dependency ranges

When a block implementation depends on another block (either
implementation or behavior), it should be able to have an 'elastic'
dependency which doesn't connect it to the versioned identifier, but to
a range of those versions.

by using another XML document that lists required features. This way it would be easy to decide if two blocks a compatible.

Those two documents, let's call them requires.xml and provides.xml,
could reside in the meta data subtree of the archive. The requires.xml
would need to declare a URI for every block it depends on which is
used to refer to it.

Example
=======
(This example is probably poor but should still illustrate the idea)


block "really cool skin"


<provides-features>
   <feature name="html-skin"/>
   <feature name="wml-skin"/>
</provides-features>

<dependencies>
   <block name="core" uri="core">
      <feature name="html-serializer"/>
   </block>
</dependencies>

<map:sitemap>
 <!-- ... -->

<map:transform src="cob:core/html-skin"/>

 <!-- ... -->
<map:sitemap>

Now, the block manager would select the block with the highest version
number that provides all required features and would map the
"cob:core" prefix to that particular block.

What you want is already achievable since the block identifier can be used to locate either a block implementation (which contains the block metadata which includes the above information) or a block behavior (which metadata can be looked up by the block deployer thru the discovery service.


In any case, let me stress out that we MUST NOT make the mistake of considering a block URI a URL or we'll limit tremendously the ability of the block system to scale and adapt to future needs.

--
Stefano.



Reply via email to