[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schemas: Best Practices

  • From: "Roger L. Costello" <costello@m...>
  • To: xml-dev@l...
  • Date: Sun, 12 Nov 2000 12:03:22 -0500

schema audi
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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.