Re: [xml-dev] Deterministic Content Models (was DTD ( From EliotteRust Harold's Book))

[Rob Lugt <roblugt@elcel.com>]

Elliotte Rusty Harold wrote:
> >
> >Not if your processor correctly disallows non-deterministic content
models.
> >However, the same expression can be written deterministically like this:-
> >
> ><!ELEMENT DIVISION (TEAM,TEAM,TEAM,TEAM,(TEAM,TEAM?)?) >
> >
>
> I disagree.  <!ELEMENT DIVISION (TEAM,TEAM,TEAM,TEAM,TEAM?,TEAM?) > is
legal in XML. No conforming validating XML parser will reject this form. A
few may choose to issue a warning for compatibility with some older SGML
parsers, and for compatibility you may choose to write the constraint in the
form <!ELEMENT DIVISION (TEAM,TEAM,TEAM,TEAM,(TEAM,TEAM?)?) >. However you
are by no means required to do so. Non-deterministic content models of this
nature are legal in XML.

Elliotte,  I disagree.  Perhaps this particular section of the XML rec is
open to some interpretation?

Section 3.2.1 [1] in the XML 1.0 Rec states:

"For compatibility, it is an error if an element in the document can match
more than one occurrence of an element type in the content model. For more
information, see E Deterministic Content Models."

This long-winded sentence appears to be referring to deterministic content
models.  In addition it indicates that the constraint should be treated as
an *error*, not a warning.  Furthermore, the "For Compatibility" clause does
not indicate that an XML processor is free to ignore the constraint.  The
definition [2] for "For Compatibility" reads: "Marks a sentence describing a
feature of XML included solely to ensure that XML remains compatible with
SGML".  Contrast this to "For Interoperability" where the XML rec explicitly
states that such constraints are non-binding on the processor.

This is not the first time that the interpretation of this section has been
questioned.  In the past I have asked for clarification [3] from the Core
WG, nothing doing so far.

Regards
~Rob

--
Rob Lugt
ElCel Technology
http://www.elcel.com

[1] http://www.w3.org/TR/REC-xml#sec-element-content
[2] http://www.w3.org/TR/REC-xml#sec-terminology
[3] http://lists.w3.org/Archives/Public/xml-editor/2001AprJun/0025.html