|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schemas: Best Practices
I've been using Abstract Elements in two contexts. In both cases I decided against using abstract typing. Let me try to document why to see if a) I had valid reasons b) it helps resolve the Best Practice debate. The first application I applies the abstract concept to was an XML Schema for ISO 13250 Topic Maps (http://www.diffuse.org/TopicMaps/schema.html). What I was seeking to do here was to show that the Schema was a template for the generation of working instances of topic maps schemas, and not intended to be used as a working schema in its own right. However, I did want to make it easy for people to import the type definitions into their working Schemas, and so decided that making the types abstract types would not help in the process of reusing the type definitions. I therefore decided that a combination on non-abstract type definitions plus abstract element definitions that could be used as the basis for substitution groups wherever there were advantages in aggregating the processing of certain elements was the best way to go. The second application I am using them on is the metamodel for core components in ebXML. Again the whole idea of these core components is to provide templates that can be used to build significant parts of a working schema. The models defined for core components are unlikely to be used without some form of qualification. In some cases only a subset of the contents will be required, in others additional components will be needed for certain conditions. There will be cases where both restriction and extension apply to the same core component. There will also be cases where all that needs to be modified are properties such as minOccur and maxOccur, or the datatyping associated with an element. In this second application there is a distinct need to keep the final message as compact as possible, and to rely on schema properties to control the processing of the document. If you are relying on schemas to provide information about things like datatyping, then you can also rely on them providing information on the type from which the model was derived. In this case we are again trying to get people away from the slavish use of a single element name to represent a class. For example, rather than having Person as the class, we want to see the element name reflect the role the person is playing in the message scenario (e.g. Buyer or Seller). Different roles normally require different processing, but shared datatypes normally indicate a shared data storage model. In our case both of these occur. For event-based processing we need role-based element names. For storage and retrieval we need to be able to identify the type the element is derived from. Now the question comes as to whether XSLT is event-based or storage-based, and whether XPath is a storage-based model or an event-based one. Here I have to admit I am on dodgy ground. I see element names as being a better control mechanism in XPath statements and XSLT select/match definitions. However, I would like to be able to have processes that depend on the substitution group an element belongs to. I think this is what I will get from using substitution groups once XPath and XSLT get updated to provide access to the substitution group data that DOM3 will need to be providing access to. Maybe I'm looking too far into the future here, but I cannot see how we can survive long without substitution groups being referencable. In the meantime we will need to rely on the unique names assigned to each member of the substitution group. Martin Bryan
|
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








