Re: Can root name in DOCTYPE be a XSD-validity thing?

C. M. Sperberg-McQueen, Thu, 14 Feb 2013 12:12:14 -0700:
> On Feb 13, 2013, at 11:13 PM, Leif Halvard Silli wrote:

>> Can a XSD-based processor validate that a XHTML5 document contains the 
>> HTML5 DOCTYPE type declaration? 
   … 
>> Note: The HTML5 DOCTYPE *declaration* doesn't reference a DOCTYPE 
>> *definition*, so I do not ask if XSD can validate the 'ExternalID' or 
>> 'intSubset' part of the DOCTYEP declaration. I only wonder if XSD 
>> allows checking that the 'name' part of the DOCTYPE matches the 'root 
>> element type'. Since it is well-formed to include DOCTYPE declaration 
>> without a DTD, and since XSD moves the validation from DTD to, well 
>> XSD, it ought, it seems, be possible to use XSD to verify that the 
>> DOCTYPE declaration contains the name of the root element (the same way 
>> that XSD allows checking many things that, per XML 1.0, does not fall 
>> under XML 1.0’s validity concept).
> 
> You are quite right that there would be no logical contradiction in 
> a schema language spec that allowed the kind of check you have in
> mind.  But no, it's not something XSD is designed to constrain, or to 
> allow schema authors to constrain.

Thanks! Perhaps, for the next update of the XSD language, you should 
consider adding support for DOCTYPE declaration validation? One use 
case: Allowing XSD to produce/validate documents that can be validated 
both via DTD or via XSD. Another use case: correct DOCTYPE declaration 
can increase the certainty that a particular schema should indeed be 
applied to the particular document.

Regardless, I just now filed a bug against the HTML5 spec suggesting 
that *if* the DOCTYPE is included, then authors should make it match 
the root element.[*]

[*] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20993


Note that the XML 1.0’s (DTD) validity concept, per the wording of the 
spec, applies even when the declaration doesn’t reference an external 
or internal DTD: [*] “[Definition: An XML document is valid if it has 
an associated document type declaration and if the document complies 
with the constraints expressed in it.]”

[*] http://www.w3.org/TR/REC-xml/#dt-valid


But one could, I guess, discuss which constraints a declaration such as 
<!DOCTYPE html> expresses. Based on a comment from David Carlisle in 
public-html@, then XML does not define (all) the ways a DTD can be 
associated with a document. And so, if the DTD is associated via one of 
those undefined means, then <!DOCTYPE html> probably represents the 
constraints of that associated DTD. But if there is no associated DTD, 
then <!DOCTYPE html> represents a document that cannot (DTD) validate 
(since the validity constraint (namely: that the root/document name of 
the DOCTYPE declaration matches the root element type defined in the 
DTD) cannot be fulfilled).

That the DTD validity rules (and thus, as well, the well-formed rule) 
applies *even* to <!DOCTYPE html> can perhaps be seen as a thing which 
allows to define entirely new (XSD-based) validity rules which 
attribute *another* meaning that root/name part of the DOCTYPE?

>> Background for my question is that XML editors/processors nowadays tend 
>> to be schema based, even when a DTD is references. And hence, if XSD 
>> doesn’t validate the DOCTYPE *declaration*, XSD could in fact label 
>> constructs like this as 'validating':
>> 
>>  <!DOCTYPE NotTheHtmlRootElement>
>>  <html xmlns="http://www.w3.org/1999/xhtml"><head><title></title>
>>  </head><body><p/></body></html>
>> 
>> And in fact, it seems most XSD processor do say that the above is 
>> validating. For example Libxml2 in XSD mode does. Just ask xmllint to 
>> apply the XHTML 1.1 XSD[1] to  a XHTML 1.1 doc with '<DOCTYPE HTML' 
>> instead of '<DOCTYPE html'[2]:
>> 
>>  xmllint --schema http://tinyurl.com/a9lrvfq http://tinyurl.com/bkhk86p

>> 
>> Even the well known Oxygen editor, which (by default) uses Xerces, does 
>> in the abvoe case behave like Libxml2. 
> 
> The agreement or disagreement of the DOCTYPE declaration with
> the name on the outermost element is not a property that affects the
> schema-validity of any document with respect to any XSD schema. 
> So I'm happy to believe that these programs behave as you say, and
> to say that their failure to object to the discrepancy between doctype
> declaration and instance has no relation to their conformance or
> non-conformance as XSD validators.

A doctype such as 
   <!DOCTYPE TheDocumentElement SYSTEM "ID" [<!--bla, bla-->] >
allows to verify

  a) that the DOCTYPE declaration is internally valid, 
     namely, that its root/document name and the DTD’s definition
     of the root element type, are matching each others,
  b) that the root/name part of the DOCTYPE declaration
     matches the actual root element of the document (except that

The b) part does not seem technically necessary since this check could 
even be performed by checking the document/root element against the 
document/root element definition found in the DTD. But, at least, there 
is a human element here. For instance, the DTD format may seem hard to 
read and often is stored externally. And so, the root/name part of the 
DOCTYPE declaration can anyhow play a technical role, namely the role 
of increasing the certainty about the human intention - that the author 
has indeed intended to author this document according to certain 
grammar.

One of the most important things that a DTD does is that it defines 
entities, e.g. character entities. And it seems that XML parser that 
are not validating, will "see" those entities regardless of the root 
element name of the DOCTYPE declaration. And, in fact, one could claim 
that that is how the HTML5 specification says that XHTMl5 parsers 
should behave, since it, for a set of 9 (expected to become 10)[*] well 
known PUBLIC identifiers, recommends to always implement the 
HTML5-defined set of character entities. 

[*] http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0211


But it is striking that these entities are implemented even when the 
document/root name part of DOCTYPE declaration does not match the root 
element.

>> ...
>> By the way: If we remove the XSD specific attributes from the markup of 
>> the above test document, then Oxygen (Xerces) does in fact complain 
>> that the root element doesn't match the document type declaration. And 
>> it does so *without* complaining that the rest of the markup is 
>> invalid. Is this because oXygen uses a XSD schema that includes DOCTYPE 
>> validation? Or is it because it uses "DTD mode" for the DOCTYPE, and 
>> then XSD mode for the rest of the document?
> 
> I think the answer is that Oxygen's algorithm for deciding how to validate 
> a document, when validation is requested, will ignore a DOCTYPE
> declaration if an xsi:schemaLocation hint is present.  (But I haven't
> tested this hypothesis; I just know that Oxygen makes its best effort to
> do something useful.)

It would be interesting to hear from someone who tests or from the 
Oxygen developers.

>> SOME "PHILOSOPHIC" QUESTIONS: According to XML 1.0, "validity 
>> constraints" apply to all valid documents. Does XML by this mean "all 
>> DTD-valid documents", noly? This is relevant since XML says that it is 
>> a validity constraint that the DOCTYPE declaration matches the root. 
>> Thus, it seems to me that if this validity constrain does *not* apply 
>> to XSD, then XSD processor are, in fact, not validating processors. 
>> (I.e. "validating processor" per XML 1.0, then means "DTD-validating 
>> processor".) If so, then in one way, it is unlucky that 'validity' is 
>> used by anything other than DTD-validity.
> 
> The only form of validity defined in the XML specification is DTD-based
> validity.  So yes, the validity constraints of that spec relate to 
> validation
> against a DTD, and no, XSD validators are not 'validating processors'
> within the meaning of XML spec.
> 
> The prose of the XSD spec generally tries to use the term 'schema-validity' 
> for the property that an XSD validator checks; there was some fear during 
> the drafting of XSD 1.0 that using the unqualified term "validity" would 
> confuse people.  The intervening years have shown that people are quite
> happy to use the term "validity" in a broader sense and to distinguish
> DTD-validity, RNG-validity, XSD-validity, etc. as needed.  So some readers
> have felt that the XSD spec's consistent use of "schema-validity" instead
> of just "validity" was an unnecessary affectation.  In future I shall refer 
> such comments to your message; you are the first reader I have encountered
> to support the XSD spec's choice of terminology.

Thanks for confirming that XSD validated documents are not XML 1.0 
valid.

Btw, I think it is good/OK when a text completely redefine a concept. 
May be it would have been just as good or better if the XSD simply used 
"valid" in the same way XML 1.0 does, but made it very clear that a) 
XML speaks about DTD-valid, whereas XSD speaks about XSD-valid.

>> PS: I note with interest that the XSD schema files for the XSD language 
>> itself, themselves (some of them) include document type declarations. 
>> And so I wonder: What would happen if one altered the root names  
>> declared by the document type declaration in those XSD documents? Would 
>> XSD-based processor stop working … ?
> 
> Most XSD processors have hard-coded knowledge of the schema
> for schema documents as specified in the XSD spec; it would be an
> unusual processor that actually read the schema document for
> schema documents on each startup.  (Not an impossible one, just
> unusual.)  Processors with hard-coded knowledge of the schema for
> schema documents would, I guess, be unaffected by a textual change
> to the schema documents in the spec.  A processor that did read the
> schema document for schema documents at startup might cease to work
> if it checked the schema documents for DTD-validity and found that
> the root element had the wrong name, but it is not (unless I am forgetting
> something) a requirement of the XSD spec that XSD schema documents
> be DTD-valid.
> 
> Thank you for your thoughtful and though-provoking message. 
> 
> I hope this helps.

Thanks. It was a great help for me!
-- 
Leif Halvard Silli

Received on Friday, 15 February 2013 11:01:02 UTC