[cddlm] what to do about <import namespace>

[Guilherme Mauro Germoglio Barbosa / Projeto Ourgrid - Projeto Ourgrid/LSD]

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?
>

Our implementation resolves this import issue using the literal 
interpretation of the specification, so we end up with (2).


> 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.
>
Unfortunately, my profile has no permissions to comment on the CDL Spec 
Revisions. Can you make me able to do this? I want to add a comment on 
https://forge.gridforum.org/tracker/?aid=1545 . My user name is: germoglio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/cddlm-wg/attachments/20060322/4fb1b840/attachment.bin