W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2000

Re: lists

From: <Noah_Mendelsohn@lotus.com>
Date: Wed, 16 Aug 2000 10:03:03 -0400
To: www-xml-schema-comments@w3.org
Message-ID: <OFB50F669B.A9B4BCCF-ON8525693D.004B2A15@lotus.com>

Among the reasons our list types are not richer is that many members of the
schemas workgroup believe that, for many purposes, structured content is
best marked up explicitly.  Otherwise, we run the risk of having to provide
the full richness of content models, once for elements as we do today, and
again for tokens in a string as you suggest.  If instead you make a complex
type to be in this style :


you can express the constraints you need.  I don't have time (sitting here
in the back of the Extreme Markup conference to write the whole schema, but
I believe you can do the following:

     <xsd:simpleType name="US-State" base="xsd:string">
          <xsd:enumeration value="AK"/>
          <xsd:enumeration value="AL"/>
          <xsd:enumeration value="AR"/>
          <!-- and so on -->

Then you can define the content of sixUsStates as a sequence of:

     <xsd:element name="sixUsStates">
               <xsd:element name="state"
                    minOccurs="6" maxOccurs="6"/>
     </xsd:element name="sixUsStates">

and then use a <xsd:unique> constraint on sixUsStates to ensure that the
six states are unique.

So, we get more explicit markup for the list in the instance document (much
easier to create and process with tools such as XSL), and we leverage the
power of existing schema mechanisms to express the constraint you are
after.  As I said above, tradeoffs like this are among the reasons that
some of us are reluctant to add too much complexity to the definition of
structured simple types.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 16 August 2000 10:57:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:53 UTC