[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schemas: Best Practices
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|