
Let me give examples on proposal [2]: <cdl:configuration> <a> <b cdl:ref="/c"/> <c>10</c> </a> </cdl:configuration> <cdl:system> <test cdl:extends="a"> <b>20</b> </test> </cdl:system> resolved as <test> <b>20</b> <c>10</c> </test> --- <cdl:configuration> <a> <b cdl:refroot="e" cdl:ref="/c"/> <c>10</c> <d>20</d> </a> <e> <c>30</c> <d>40</d> </e> </cdl:configuration> <cdl:system> <test cdl:extends="a"> <b cdl:ref="/d"> </test> </cdl:system> resolved as <test> <b>20</b> <c>10</c> <d>20</d> </test> --- <cdl:configuration> <a> <b>10</b> <c>20</c> </a> </cdl:configuration> <cdl:system> <test cdl:extends="a"> <b cdl:ref="/c"/> </test> </cdl:system> resolved as <test> <b>20</b> <c>20</c> </test> Jun Tatemura wrote:
I propose two modifications on the spec to address issues we have discussed. I hope this will not be a huge change...
[1] Remove "import with namespace specified" from the spec.
This has been introduced to address namespace conflict at the user side. However, it turned out that this introduces complication we did not initially expect, as pointed out in the discussion with Steve and Rakesh. Since namespace itself is meant to address name conflict, why don't we let namespace work on that. Instead of making it more complicated with patches, I propose to remove cdl:import/@namespace from the spec and add a "guidance" (or best practices) as follows:
-- "When the provider publishes a CDL document for component description, which is likely to be combined with ones from different providers, the provider SHOULD use a unique namespace for the toplevel elements."
The user side should stop worrying about importing something into a new namespace at his own risk and start blaming the careless provider who published conflicting names.
[2] On prototype resolution, treat a reference and a value interchangeably:
On prototype resolution, (1) a value reference (a pair of @cdl:refroot and @cdl:ref) is overridden by either a value reference or a property value (child nodes); (2) a property value (child nodes) is overridden by either a value reference or a property value.
-- I will be attending tomorrow's call to discuss.
Best Regards, Jun Tatemura