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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: XML Schemas: Best Practices

[ Lists Home | Date Index | Thread Index ]
  • From: Eve.Maler@East.Sun.COM (Eve Maler - Sun Microsystems)
  • To: xml-dev@lists.xml.org
  • Date: Thu, 12 Oct 2000 16:18:25 -0400

"Roger L. Costello" <costello@mitre.org> wrote:
>Summary:
>
>"Here are guidelines for when to declare an item as an element versus
>when to define it as a type: during the lifespan of an item, if it is to
>be associated with multiple semantics then create a type definition. 
>If, on the other hand, the item's semantics are to remain constant over
>its lifetime, but multiple synonyms/aliases are to be used for the item
>then declare it as an element."
>
>Do you agree with these guidelines?  Perhaps these guidelines are too
>abstract?  If you were given these guidelines would you be able to make
>a decision on whether to define an item as an element or as a type?  Are
>there other things that you would add to the guidelines?  /Roger

I think it's not really right to suggest that different element names never 
add to the meaning of a type.  Clearly, the SydneyElevation element
declaration would add a layer of meaning to the Elevation type, even if the 
new layer doesn't result in tangible differences to the "signature" of the 
type (its content model or attribute list).  You can imagine both applications
that are interested in all things of type Elevation *and* applications that
are only interested in elevations in Sydney.

I would say that if an item has some core semantics on which it would be useful 
to layer different sets of additional semantics, you should use a named type --
but this is only because the particular design of XML Schema only allows you to do 
this layering with types and not with elements.

Elements are like "final" and "concrete" types because XML Schema does not 
allow them to be derived from and because they have a direct representation 
in instances.  But several schema language proposals over the last couple of 
years have done away with the element/type distinction, proving that they
have many semantic-ish characteristics in common.  (After all, SGML and XML
didn't have the distinction to begin with.)

	Eve





 

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

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