xml-dev - Re: XML Schemas: Best Practices

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

From Mike Ripley:

I'd like to comment on the issue of semantics of Chameleon components.

Basically, I don't agree with this assertion:

>So, not only can the Chameleon components incorporate into many
>different namespaces, but also, they can have multiple different
>semantics, i.e., different semantics in each schema they are used
>within.

Although this is technically true, as a best practice I think we 
should come out against this.  I also think allowing different 
semantics in each schema subverts the real reason why you would 
create Chameleon components to begin with - reuse.

The basis of reuse is there's something in common to reuse.  In the 
data modeling domain (BTW, I believe the overall topic of 'XML 
Schemas: Best Practices' is 80% data modeling and 20% XML), the 
common thing to reuse is common semantics.  If I don't have common 
semantics then I have no real reason to reuse schema components.  So 
I would assert that the motivation for creating and maintaining 
Chameleon components is common semantics.  Notice that, in fact, your 
car example in the two namespaces of "products" and "reviews" uses 
the same semantics for <car>.

Given this, the advantages of redefining can now be thought of in 
terms of refining the semantics of some Chameleon component to meet 
the specific semantics of the schema being created.  So for example, 
I might refine <car> to have enumerated types for the specific cars 
I'm dealing with (e.g., say I work for Audi and I only need to have 
Audi cars in my schema).  The semantics have been refined from 'all 
cars' to 'Audi cars', but it's still the same type of entity being 
modeled.  If, on the other hand, I work for Amtrak, I shouldn't use 
the Chameleon component <car> to hold railroad cars, since 
semantically these are different types of entities.

I think this approach also limits the 
"component-change-impact-rippling-problem" raised by Mary 
Pulvermacher.  Changes to Chameleon components will be limited to 
changes that still maintain the component's semantics, so something 
won't break downstream due to a semantic change in a Chameleon 
component.

rip