xml-dev - Re: XML Schemas: Best Practices

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

Thanks for all the excellent feedback on defining the limitations of the
Chameleon Namespace design! [Sam, I am working on an example.  Thanks
for keeping me honest.]

Let me try to summarize the comments:

Toivo pointed out that because a no-namespace component can take on many
faces (i.e., namespaces), it will be difficult to create a tool that can
process the no-namespace component regardless of what namespace it has
attached itself to.  [Is this an accurate summary Toivo?]

Ron makes two points:
1) Name collisions. If any of the chameleon components collide with
components you are defining/declaring in your schema, you need
namespaces to disambiguate them.
 
2) Code reuse. Any standard code written for the chameleon components
might need to be rewritten for each schema in which those components are
included. [I believe that this is the same argument that Toivo makes
above.  Do you concur Ron?]

Okay, so we have come up with two limitations on the Chameleon Namespace
design:

1. Name collisions.
2. Tools to process the no-namespace components.

Limitation (1) I agree with.  It is also a limitation of the Homogeneous
Namespace design. I consider this a minor limitation.  It simply is a
matter of being careful that the Chameleon components that you are
reusing don't clash with your own components.  Do you agree?

Hmm, perhaps (2) is not really a limitation at all.  Consider this idea:

Is it possible to create namespace-independent tools, i.e., tools that
can process the Chameleon components no matter what namespace they
reside in?  Taking Toivo's example, imagine a tool that can process the
Chameleon <car> element in either namespace:

> <productinfo xmlns="www.products.com">
>    <car>Honda Civic</car>
>    <price>$16,000</price>
>    ...
> </productinfo>
> 
> <userreviewsummary xmlns="www.reviews.com">
>    <productreviewed><car>Honda Civic</car></productreviewed>
>    <rating max="5">4.7</rating>
>    ...
> </userreviewsummary>

How does the tool recognize that the <car> element is the Chameleon
component that it was created to process?  Answer: The tool understands
what is the valid structure and datatype of the <car> Chameleon
component.  By examining the datatype and structure of the element in
the instance document (the Post Schema Validation (PSV) Infoset will
provide such information) the tool can determine whether or not the
<car> element it encounters is in fact the Chameleon <car> component. 
In addition, elements and types can have an id attribute associated with
them.  This could be used to uniquely identify a Chameleon component.  

I am starting to get excited about this idea - tools that can recognize
and process Chameleon components no matter what namespace the components
take on.  Wow!!!  These Chameleon components are even more powerful than
I envisioned.  What do you think?  /Roger