This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf5015?nav=1&selectedTab=history at Sun, 06 Nov 2022 16:29:08 GMT SourceForge : artf5015: (1782) Need to clarify the semantics of <import namespace>

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: CDDLM-WG     Trackers > CDL Spec Revisions > View Artifact
Artifact artf5015 : (1782) Need to clarify the semantics of <import namespace>
Tracker: CDL Spec Revisions
Title: (1782) Need to clarify the semantics of <import namespace>
Description:
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. 



 .
Submitted By: Steve Loughran
Submitted On: 03/22/2006 10:50 AM EST
Last Modified: 03/22/2006 10:50 AM EST

Status / Comments Change Log Associations Attachments  
Field Old Value New Value Date Performed By
No results found.

 
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf5015?nav=1&selectedTab=history at Sun, 06 Nov 2022 16:29:09 GMT