[cddlm] what to do about <import namespace>

[Jun Tatemura]

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

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.