xml-dev - Re: XML Schemas: Best Practices

[Ronald Bourret <rpbourret@rpbourret.com>]

"Roger L. Costello" wrote:
> 
> 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?]

Yes.

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

This really depends. The names in your schema are your user interface,
and if you've ever tried to define a user interface, you'll know that
sometimes it works just fine and sometimes it can be extremely
difficult.

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

To be nitpicky, this is not guaranteed to disambiguate two names. For
example, the classic ship-to/bill-to address example couldn't be
disambiguated in this way and if for some reason they were both named
Address but came from different schemas...

On a more serious note, I don't think this would lead to very efficient
code. It may be possible to write code that can recognize names without
namespaces, or that can somehow adapt to this situation, but this isn't
the way to do it.

As another question, how are Chameleon elements schema-validated? In the
example above, how does the validation software know which content model
to apply to <car>? I could be wrong but I thought that the schema spec
said that validation was done based on qualified element type name. Or
does this rule simply not apply because the element type is local to its
containing element type?

-- 
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com