OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XML Schema: Best Practices

[ Lists Home | Date Index | Thread Index ]
  • From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
  • To: "'xml-dev@lists.xml.org'" <xml-dev@lists.xml.org>
  • Date: Thu, 19 Oct 2000 14:59:49 -0600

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>




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS