[cddlm] what to do about <import namespace>

[Steve Loughran]

Jun Tatemura wrote:
> Hi, team
> Sorry for the late reply.
> 
> I propose to take Steve's second solution, that is:
> 
> namespace definition on import is applied only to
> toplevel elements with namespaces unspecified.
> 
> The reason why we want to define namespaces at the user's side is to
> resolve name conflicts if any. Here the solution must have the following
> two properties:
> 
> (1) the solution must be sufficient
> meaning that: the solution must resolve any namespace
> conflicts caused by import
> 
> (2) the solution must be safe
> meaning that: the resolved CDL document must be understandable
> for the component providers (this is the problem Seve pointed out).
> 
> The following discussion shows that the above solution is sufficient and 
> safe.
> 
> [1 sufficiency] Assume that user U1 writes a CDL by importing CDLs from
> two component providers P1 and P2. Critical conflicts are ones between
> P1 and P2 since U1 does not have control on what P1 and P2 wrote.
> Note that conflicts between U1 and P1 can be resolved
> if U1 uses namespaces appropriately.
> 
> Conflicts between P1 and P2 can happen when they use the same name on
> component templates (i.e. toplevel elements). There should be a way for U1
> to uniquely specify one of these by @cdl:extends and @cdl:refroot
> 

I concur. The only thing we need to be sure of is reference resolution 
within imports and references are fully consistent. Tests like

-you can cdl:extends something in the local ns in an imported document, 
it will still resolve even once imported into an xmlns

-if you import something into a namespace, non-lazy cdl:root references 
to local names get resolved to the elements in the new namespace

-same for lazy references

All contributions welcome; please add (non-lazy) tests to the _imports 
tests; Lazy stuff will have to be postponed until CMP tests.






> On the other hand, conflicts will not happen between component properties
> (i.e. non-toplevel elements) from P1 and P2,  since:
> - CDL does not support multiple inheritance
> - CDL's inheritance is applied only to child elements
> (not applied to deep structure). Thus, hierachical use of
> @cdl:extends such as
> <a cdl:extends="x"><b cdl:extends="y">...</a>
> will not introduce conflicts.
> 
> The fact that no conflict between non-toplevel elements
> during inheritance implies that any conflict can happen
> between sibling elements -- if there are two elements with
> the same name under the same parent, they must come from
> the same provider (unless the user wrote them).
> This means that a path in the CDL reference will not be affected
> by any conflict (note that the CDL path expression does not support
> '//'). Thus, a value reference can have conflicts only
> at @cdl:refroot (i.e., toplevel elements).
> 
> [2 safety] Both prototype resolution and value resolution copy
> children of referred elements and do not copy
> the referred element themselves. Thus, the name of
> a toplevel element will not appear in the resolved CDL
> document.
> 
> 
> One argurable point is what we should do when the provder
> specifies a namespace on toplevel elements. We assume that
> a namespece is specified so that uniqueness issue between
> providers are resolved by themselves (uniqueness of
> namespaces are commonly assumed in many other cases).
> 
> 
> Steve Loughran wrote:
> 
>>
>> I just had the phone conf thing turned on, but nobody dialled in, so 
>> we didnt get an opportunity to talk about <import namespace>. That's 
>> OK. it has given me more time to deal with SOAP problems. For the 
>> curious, I am abandoning Axis2 because all it brings to the table is 
>> pain. They've done some fancy new classloader stuff, which, coupled 
>> with the preponderance of the code to catch and inadequately log 
>> exceptions, means you can spend forever debugging it.
>>
>> Instead we will be using the long-promised Alpine SOAP stack :) I'm 
>> still trying to have something ready by the end of the week, even if 
>> it is just the portal. One problem will be the AddFile() operation, 
>> because implementing attachments will be tricky.
>>
>> Returning to the other troublespot: what are we to do about <import 
>> namespace>?
>>
>> This is what I have filed in the CDL issue tracker, under 
>> https://forge.gridforum.org/tracker/?aid=1782
>>
>> Need to clarify the semantics of <import namespace>
>> ===================================
>>
>> The CDL specification, on the topic of <import namespace>, doesnt 
>> cover what to do if stuff is already is in a namespace, and implies 
>> that all attributes and elements in the list also get pulled in.
>>
>> As a consequence, when something gets imported into a namespace, 
>> everything inside it gets moved
>> into the new namespace, so is no longer accessible to components that 
>> are trying to resolve it
>> using the local name.
>>
>> To show this as an example, (from 
>> /cdl/valid/set_09_import_namespace/cddlm-cdl-2005-09-0001.xml )
>>
>> At http://cddlm.org/test1.cdl there is a file with no namespace
>>
>> <cdl:cdl>
>>   <cdl:configuration>
>>     <WebServer>
>>       <hostname>localhost</hostname>
>>       <port>80</port>
>>     </WebServer>
>>   </cdl:configuration>
>> </cdl:cdl>
>>
>> this is imported into a new namespace
>>
>> <cdl:cdl xmlns:test1="http://cddlm.org/test1.cdl">
>>   <cdl:import location="http://cddlm.org/test1.cdl"
>>       namespace="http://cddlm.org/test1.cdl"
>>       />
>>   <cdl:system>
>>     <MyServer cdl:extends="test1:WebServer">
>>       <hostname>www.cddlm.org</hostname>
>>     </MyServer>
>>   </cdl:system>
>> </cdl:cdl>
>>
>>
>> Now, what do we end up with? Is it (1)
>>
>>   <cdl:system xmlns:test1="http://cddlm.org/test1.cdl">
>>     <MyServer>
>>       <hostname>www.cddlm.org</hostname>
>>       <port>80</port>
>>     </MyServer>
>>   </cdl:system>
>>
>> Or is it (2)
>>
>>   <cdl:system xmlns:test1="http://cddlm.org/test1.cdl">
>>     <MyServer>
>>       <hostname>www.cddlm.org</hostname>
>>       <test1:hostname>www.cddlm.org</test1:hostname>
>>       <test1:port>80</test1:port>
>>     </MyServer>
>>   </cdl:system>
>>
>> (2) is the literal interpretation of the specification, and it is 
>> wrong, because nested elements are now in the wrong namespace for 
>> their implementation classes to be able to read.
>>
>> Solutions
>>
>>  -pull the whole namespace stuff out, tell people to use their own 
>> namespaces for scoping.
>>   and stick to <import>
>>
>>  -restrict namespace scope to the qnames of the toplevel elements. 
>> Leave stuff already in namespaces
>>  alone.
>>
>> What have other projects done?
>>
>> I looked at how Ant's ability to <typedef> a task or type into a 
>> namespace. It only acts on the supplied tasks and types in the local 
>> namespace, and maps all attributes into the same xmlns. For
>> nested elements it does something devious and allows either namespaced 
>> or local declarations in
>>
>> <taskdef name="myecho" uri="antlib://ex.org.package" />
>>
>>
>> this would make the following things identical, assuming
>> xmlns:m="antlib://ex.org.package"
>>
>>
>> <m:echo level="info" >
>>   <message>text here</message>
>> </m:echo>
>>
>> and
>>
>> <m:echo m:level="info">
>>  <m:message>text here</m:message>
>> </m:echo>
>>
>> That is: stuff inside the new task is both inside the new namespace, 
>> and in the ##local namespace. Ant pulls this off because it does its 
>> O/X mapping from the outside, going from XML elements to java methods, 
>> and can do loose matching of QNames to methods.
>>
>>
>> We dont have that option in CDL, so need a better solution
>>
>> ----------------------
>>
>> As an aside, there are a currently 6 outstanding defects in the tracker:
>>
>> https://forge.gridforum.org/tracker/?atid=734&group_id=130&func=browse
>>
>> I believe this is the official way to file issues against a spec, but 
>> if it would be better for me to file pointers to the items in a 
>> different tracker as part of the public review, I can do that.