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. 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.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
