• From: "Arnold, Curt" <Curt.Arnold@h...>
• To: "'xml-dev@i...'" <xml-dev@i...>
• Date: Mon, 27 Sep 1999 15:24:39 -0600

One of the things that has been troubling me with today's schema working
draft release is the reduction of the effectiveness of validating a schema
with the schema DTD.  For example, in the previous draft, an element with an
empty content model was represented by

<elementType name="emptyElement">
	<empty/>
</elementType>

The <empty> element was defined as having an empty content model, so the
following fragment would result in a validation error.

<elementType name="emptyElement">
	<empty>
		<elementTypeRef name="otherElement"/>
	</empty>
</elementType>

In todays, draft the same thing poorly formed element would be represented
by

<element name="emptyElement">
	<archetype content="empty">
		<element name="otherElement"/>
	</archetype>
</element>

and would validate.

Also, the <datatype> element definition in the schema for datatypes uses the
"all" compositor (equivalent the SGML &) which allows each of the different
facets to appear once, but in any order.  Since the all compositor was not
included in XML, the closest a DTD can do is allow any of the elements to
appear in any order any number of times.  It would seem better for the
schema to define a specific order so that the DTD could enforce the number
of times a particular facet appears.

The changes appear intentional from the previous draft and I'm sure there is
reasoning (and probably a huge amount of debate) behind it.  However, I
really liked the <choice>, <sequence>, <any> and <empty> tags from the
previous public draft.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: CDataSection in Node
• Next by Date: Identical production rules
• Previous by thread: CDataSection in Node
• Next by thread: Identical production rules
• Index(es):
  • Date
  • Thread