Re: XML Schemas: Best Practices
Hi Folks, I would like to move on to the next schema design issue: Issue: When should an element or type be declared global versus when should it be declared local? [Recall that a component (element, complexType, or simpleType) is "global" if it is an immediate child of <schema>, whereas it is "local" if it is not an immediate child of <schema>, i.e., it is nested within another component.] If someone were to ask you, "In general, when should an element or type be declared global versus when should it be declared local?", what advice would you give them? A month ago I would have answered, "as a general rule, make things global". However, after the discussions that we have had, I would have a very different answer today. Example. Below is a snippet of an instance document. Let's explore the different design strategies for defining <Book> and its components. <Book> <Title>Illusions</Title> <Author>Richard Bach</Author> </Book> One design approach is to mirror the instance document - declare a Book element and within it declare a Title element followed by an Author element: First Design: <element name="Book"> <complexType> <sequence> <element name="Title" type="string" minOccurs="1" maxOccurs="1"/> <element name="Author" type="string" minOccurs="1" maxOccurs="1"/> /> </sequence> </complexType> </element> That's one end of the design spectrum. At the other end of the design spectrum: we disassemble the above instance document into its individual components, define each component, and then assemble them together: Second Design: <element name="Title" type="string"/> <element name="Author" type="string"/> <complexType name="Publication"> <sequence> <element ref="cat:Title" minOccurs="1" maxOccurs="1"/> <element ref="cat:Author" minOccurs="1" maxOccurs="1"/> </sequence> </complexType> <element name="Book" type="cat:Publication"/> These approaches represent both ends of the design spectrum. For this issue, I like to think in terms of boxes, where a represents an element or type. Thus, - The first design approach corresponds to having a single box, and it has nested within it boxes, which in turn have boxes nested within them, and so on. - The second design approach corresponds to having many separate boxes which are composed together. The composition of the boxes creates the whole. I believe that it will be useful to create a name for the two design approaches: - What name would you give to the design strategy where the components (i.e., element declarations and type definitions) are nested within each other? It is the "xxxxx" design approach for schema construction. - What name would you give to the design strategy where components are defined individually and then composed together? It is the "yyyyy" design approach for schema construction. Let's examine the characteristics of each of the two design approaches. (Perhaps the characteristics will yield insights into appropriate names for the two design approaches?) First Design Characteristics:  Opaque content. The content of Book is opaque to other schemas, and to other parts of the same schema. The impact of this is that none of the types or elements within Book are reusable.  Localized scope. The region of the schema where the Title and Author element declarations are applicable is localized to within the Book element. The impact of this is that if the schema has set elementFormDefault="unqualified" then the namespaces of Title and Author are hidden (localized) within the schema.  Compact. Everything is bundled together into a tidy, single unit. Second Design Characteristics:  Transparent content. The components which make up Book are visible to other schemas, and to other parts of the same schema. The impact of this is that the types and elements within Book are reusable.  Global scope. All components have global scope. The impact of this is that, irrespective of the value of elementFormDefault, the namespaces of Title and Author will be exposed in instance documents  Verbose. Everything is laid out and clearly visible. I am sure that there are other characteristics that I am missing. Can you please help to list them? As I see it, the major tradeoff between the two design approaches is - The first design approach facilitates hiding (localizing) namespace complexities - The second design approach facilitates component reuse. (I find it interesting that this issue is relating back to the issue we discussed earlier on when to hide (localize) namespace complexities within the schema versus when to expose the namespaces in instance documents.) Here's a summary of things to be resolved for this issue: (1) What name do we give to (what I have been calling) First Design? (2) What name do we give to (what I have been calling) Second Design? (3) What are the other characteristics of the two design approaches? (4) What do you see as the main tradeoffs in the two design approaches? Thanks! /Roger
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