xml-dev - Re: XML Schemas: Best Practices

["Roger L. Costello" <costello@mitre.org>]

Hi Folks,

Last week I asked for people to help me understand the limitations of
using the Chameleon Namespace design approach.  Toivo, Ron, and Curt
came up with two limitations of this design approach.  Here is the
second limitation: (see the previous message for discussion of the first
limitation)

b. Tools for Chameleon components.  We have seen repeatedly how
Chameleon components are able to easily blend in with the schemas that
they reside within.  That is, they adopt the namespace of the schema
that they reside within.  How do you write tools for such components
when they can assume so many different faces (namespaces)?

My response to this.  I wonder if you would even want to write tools for
Chameleon components?  Since Chameleon components are independent of
context (namespace) then it makes me question whether you would want to
write tools for such context-independent components?  It seems to me
that the tools should be written for the schemas which incorporate the
Chameleon components.  What do you think?

For the sake of argument, let's suppose that it does make sense to write
tools to process Chameleon components.  Consider this no-namespace
schema:

1.xsd
   A
   B

Suppose that we create a tool, T, which is able to process the two
Chameleon components A and B, regardless of what namespaces they end up
in.  Now imagine a schema, main.xsd, which <include>s 1.xsd.  In
addition, suppose that main.xsd has its own element called A.  For
example:

main.xsd
targetNamespace="http://www.example.org"
<include schemaLocation="1.xsd"/>
<include schemaLocation="2.xsd"/>
<element name="stuff">
   <complexType>
      <sequence>
         <element name="A" type="xxx"/>
         ...
      </sequence>
   </complexType>
</element>

How would the tool T be able to distinguish between the Chameleon
component A and the local A?  

One simple solution is that when you create Chameleon components assign
them a global unique id (a GUID).  The XML Schema spec allows you to add
an attribute, id, to all element, attribute, complexType, and simpleType
components.  This id attribute can be used by a tool to "locate" a
Chameleon component, regardless of what "face" (namespace) it currently
wears.  That is, the tool opens up an instance document using DOM, and
the DOM API will provide the tool access to the id value for all
components in the instance document.

What if the network is down and the DOM is not able to access the schema
to bring in the schema information?  There is no difference than today's
tools where there are DTDs.  For example, suppose that my instance
document has a DOCTYPE declaration which asserts that the instance
document conforms to a DTD.  If I run a tool like an XSL Processor
(e.g., XT) and the DTD is not accessible then XT will crash.  The
solution of course is to make a local copy of the DTD.  Likewise, for
our Chameleon component tool the solution is to make a local copy of the
instance document's schema and all the schemas that it imports/includes.

Okay, what do you think about that?  We are making some real good
progress on the Chameleon Namespace design.  Wonderful!  /Roger