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

Re: equivClass in element vs. complexType

From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
Date: 24 Mar 2000 09:32:00 +0000
To: "Eric Rehm" <rehm@singingfish.com>
Cc: <www-xml-schema-comments@w3c.org>, XML Developers List <xml-dev@xml.org>
Message-ID: <f5b66ucogrz.fsf@cogsci.ed.ac.uk>
"Eric Rehm" <rehm@singingfish.com> writes:

> It seems odd that I cannot declare the equivClass in a complexType
> declaration.
> Perhaps I am thinking too much like a the Java/C++ developer that I am, but
> would rather define this "inheritance" when I was defining the type, i.e.,
> the
> <complexType>.
> Perhaps I misunderstand the difference between the <complexType> and
> <element>
> declarations?

Sorry not to reply sooner, busy with recent internal release.  I'm not 
sure I understand the question.  Equivalence class define a
substitution set for elements:  if <sub> is declared with <super> as its
equivalence class exemplar, then where references to <super> appear in 
content models, <sub> appear as well as <super> in instances.

The closest parallel for type definitions is xsi:type -- if _derived_
is derived from _base_, then where elements declared as of type _base_ 
appear in content models, that element may appear in instances, but
with "xsi:type='_derived_'", and it will be validated by _derived_.

The reason we require the signal in the instance was to avoid
open-ended back-tracking at parse time -- if elements were allowed to
take any derived type of there declared type, a parser might have to
try them all until it found one that worked.

Hope this helps -- if it doesn't, please supply a more specific

  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/
Received on Friday, 24 March 2000 04:32:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:46 UTC