W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2001

Re: simple types = complex types (sometimes) ?

From: <Noah_Mendelsohn@lotus.com>
Date: Mon, 19 Mar 2001 16:17:48 -0500
To: Helena Cavanagh <helena.cavanagh@usa.net>
Cc: www-xml-schema-comments@w3.org, www-xml-schema-comments-request@w3.org
Message-ID: <OF4746DE3C.9F849DB7-ON85256A14.00731E4B@lotus.com>
Helen Cavanagh writes:

>> <complexType>
>>      <simpleContent>
>>              <extension base="string"/>
>>      </simpleContent>
>> </complexType>
>> now, isn't this exactly the same as a simple type definition

No, actually there are a number of interesting ways in which it is 
different.  The most striking is that you have constructed a complex type, 
which means a type that you can use only for elements.  You cannot use the 
new type for an attribute.  The the new type also necessarily has a 
different name, or no name.  More on this in a minute. 

To understand the deeper significance, realize that you might well have 
asked the same question about a trivial simple type derivation:

        <simpleType name="city">
          <restriction base="string">

This type is even more similar to string, and can indeed be used for both 
elements and attributes.  Still, it has uses.  It is very common in 
programming languages to use constructions of this sort.  When you 
validate, you will be told that your elements or attributes were of type 
"city";  that might be useful to your application.  Furthermore, if you 
are using element substitution groups, then:

        <element name="CitySubstitutionGroup" type="ns:city"/>

can be substituted by other elements of type city, but not by elements of 
type string.  There is an expectation that future versions of XSL and 
specifically XPath will allow matching by type name.  This would make it 
trivial to perform operations such as "format all cities in italics", 
without catching other types of string.  Thus, having otherwise similar 
types with different names is indeed significant and useful.

Finally, it is not uncommon in languages of this sort to have 
constructions which in their degenerate uses are of marginal value, but 
which provide a uniform framework when used in more likely scenarios.  In 
the case of extension, most extensions will be nontrivial. 

So, that should give you some idea of why you might want to do this sort 
of thing, and why the feature is as it is.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Monday, 19 March 2001 16:19:35 UTC

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