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

RE: XML Schema: Best Practices

  • From: "Arnold, Curt" <Curt.Arnold@h...>
  • To: "'xml-dev@l...'" <xml-dev@l...>
  • Date: Thu, 19 Oct 2000 14:59:49 -0600

elementformqualified
I guess I'm just a slicer.  I don't think the example is representative or the conclusions general.  Basically, you have one class (Book) with an attribute (Title) and a role name (Author).  The
example does address associations between classes.  It is when you start looking at the implied class "Person" that you may want to use in other contexts does local-scoping start causing problems.

Using local-scoped elements (or equivalently, element attributes) for class attributes or role names is appropriate (but not mandatory).  But, if an element corresponds to an class that has the
slightest potential for reuse in other contexts, I would recommend that it would be a global-scope element (or at least a global-scope complex type).  

Locally-scoped elements to represent classes is roughly equivalent to using inner classes in Java and should be used in roughly the same way, when the class is so specialized to its context that it
has no potential for reuse outside of that context.  In also in a similar manner, use of inner classes requires you to use later versions of Java, use of local-scope elements means that DTD validation
becomes problematic.

Using the Venetian Blind approach with elementFormQualfied doesn't result in global-scope elements that can be used from other namespaces or in other instances.  It defines a local-scope elements that
are only usable in their context.  I can't, for example, ever use <Author> independently of <Title>.  In addition, though it is only one change in the schema, changing elementFormQualified could
result in substantial changes in processing code.  

I'm actually much more concerned about the complexity introduced to application writers than any minor readability issues for humans.  And of course, use of unqualified elements complicates use of a
default namespace, so it might actually add more namespace prefixes than it eliminates.

p.s. Roles and Classes

In general, I like to use a distinct element for a class.  However, the classic "BillTo" and "ShipTo" example (which seems to motivation for the introduction of a reusable complexType) and the
"Author" in this example, basically merge the role and the class into one element.  If you do this, then the class should be represented as a global-scope type.


<xsd:complexType name="Person"/>
<xsd:element name="Book">
	<xsd:complexType>
		<xsd:element name="title" type="xsd:string"/>
		<xsd:element name="author" type="Person"/>
	</xsd:complexType>
</xsd:element>

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.