Re: Clarify that documents with DOCTYPE but without markup declaration are not subject to validation

Thank you for your continued interest in this matter.
The XML Core WG has discussed this issue in some detail,
and the WG members do have varying thoughts on the matter.
As I indicated in my earlier message, it did not answer
all questions.

Speaking just for myself, not the WG, my major opinions are:

1.  The XML spec, which defines two processing modes
     (validating and non-validating) does not and should not
     say anything about when to use which mode.

2.  It is certainly the case that nothing in the document
     (e.g., the existence or non-existence of any form of
     doctype declaration) has been defined by the XML spec
     to indicate which processing mode to use.

3.  Therefore, a tool that does not allow itself to be used
     as a non-validating processor in the presence of a
     doctype declaration is not a tool to be used to process
     such things as HTML5.  (Short of a tool uniquely designed
     to be a validator, I would expect any well-designed tool
     to have a "non-validating mode" and a way to put that tool
     into that mode regardless of anything in the document.)

4.  The XML spec could be augmented to clarify that a document
     is valid only if it has an associated document type
     declaration and if the document complies with the
     constraints expressed in it and the document violates
     no validity constraints.  It should not be amended to
     make any distinction between document type declaration
     constraints and validity constraints, and it should not
     be amended to made a special case out of any particular
     document type declaration (e.g., an "empty DTD").

The XML Core WG will consider your latest postings further
(it may take a while, as we met every other week), and we
will probably eventually have some further WG response.

paul

On 2014-02-06 06:07, Leif Halvard Silli wrote:
> Paul Grosso, Wed, 05 Feb 2014 11:19:49 -0600:
>
>> HTML5 can make its own rules about how a tool should process
>> documents. Admittedly, if a tool is using an XML processor
>> to process an HTML5 document, it should probably not use
>> validation mode, but that is not something for the XML spec
>> to address.
> My motivation is clearly related to HTML5. But I don’t make no special
> plea for HTML5.
>
> For instance, if one was to develop a official - or unofficial - DTD
> for HTML5 documents, it would make sense for XML tools to default to
> handle such documents the same way they handle other documents that
> associate a DTD via a document type declaration. Some other default
> behavior for such documents would certainly be possible, but
> counterproductive, to ask for.
>
> However, today, when a document is "not valid", it typically triggers
> DTD-free forms of conformance check, such as XSD-based and other
> non-DTD-based conformance sevices. For such documents, ”not valid” is
> often viewed as synonymous with ”without DOCTYPE”. (Btw, ”DOCTYPE”, as
> a shorthand for ”document type declaration”, is not found in XML 1.0!)
>
> For that reason it is quite important to maintain that it is *no hack*
> to realize that even documents *with* a doctypedecl construct are
> simply “not valid” and nothing more if the doctypedecl construct of the
> document contains or points to no DTD.
>
> Further more, because HTML5 has become so important and because I would
> like to use XML tools on HTML5 documents problem free, it is also
> important to stress that notifying the user about broken validity
> constraints for documents that are simply ”not valid”, is not in line
> with how validation is prescribed to happen.
>
> It is not the first time a document class has been defined without
> reference to DTD. But it might be the first time the (empty) mechanism
> for offering a DTD - the doctypedecl - has been prescribed by such a
> document class. And this is why it has become somewhat important not to
> change anything, but to point out the facts that I outlined above.
>
> Thank you for your attention.

Received on Thursday, 6 February 2014 17:09:32 UTC