|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schemas: Best Practices
"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
|
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
|
|||||||||

Cart








