xml-dev - Re: XML Schemas: Best Practices

["Thomas B. Passin" <tpassin@home.com>]

Roger L. Costello wrote, replying to Mike Ripley:

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

Analogous to type restrictions as used in xml-schema - the
recommended practice would exclude the analog of type
extensions.  I agree.

I'm not so sure about talking about "refining  the
semantics", though.  Any semantics are hidden in the model
(which may not formally exist) behind the component, and can
only be gotten at by reverse engineering the component or by
reading documentation about the component.  A person (a
re-user, not the original creator) would have to refine the
component based on a hypothesis about the original
semantics, not based on the component itself per se.  Good
naming helps with this, of course.

Cheers,

Tom Passin