[cddlm] what to do about <import namespace>

[Steve Loughran]

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.