W3C home > Mailing lists > Public > public-html@w3.org > March 2010

RE: ISSUE-4 (html-versioning) (vs. ISSUE-30 longdesc)

From: Larry Masinter <LMM@acm.org>
Date: Sun, 28 Feb 2010 18:43:23 -0800
To: "'Maciej Stachowiak'" <mjs@apple.com>
Cc: "'Toby Inkster'" <tai@g5n.co.uk>, "'Adam Barth'" <w3c@adambarth.com>, "'HTML WG'" <public-html@w3.org>
Message-ID: <000b01cab8e8$f7287e30$e5797a90$@org>
I think you missed the point of validation. Some organizations
might well want HTML subsets  -- no heading elements, no tables,
but inline markup, for example -- the kind of thing you find
often in comment fields.  HTML5 doesn't have a DTD, but it
doesn't mean you can't use a DTD for a subset in a controlled
workflow. The example of workflows which are producing content
that is validated using a tool that tests for a particular
style or technical elements in order to meet accessibility 
guidelines is just one example.

The fact that you can't validate "full" HTML with them
is irrelevant, that's not the workflow. There are interesting,
useful *subsets* of HTML5 that can be validated with a DTD.

And the question about whether there's a DOCTYPE or
a schema is not really relevant to the point: the point
is, if you want to chose between a version attribute
and the DOCTYPE, they already have documentation and
training and infrastructure that deals with DOCTYPE
and doesn't deal with version attributes.

For a specification to try so hard to "match reality"
for deployed content, "matching reality" for deployed
editors and infrastructure and documentation and
training should get some weight too.

Larry


-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Sunday, February 28, 2010 6:28 PM
To: Larry Masinter
Cc: 'Toby Inkster'; 'Adam Barth'; 'HTML WG'
Subject: Re: ISSUE-4 (html-versioning) (vs. ISSUE-30 longdesc)


On Feb 28, 2010, at 5:43 PM, Larry Masinter wrote:

> There was another use case that pushed me toward continuing
> with DOCTYPE, which is the extensive use of DOCTYPE in XML/XHTML
> editors.

I vaguely recall that last time this came up, further discussion found

that none of these tools seemed to actually depend on a version- 
bearing DOCTYPE declaration. But I did a quick check myself:

>
http://manual.altova.com/XMLSpy/spyprofessional/index.html?xshtmlcssjs
on_html.htm

Accepts either a DTD or an XML Schema, for XML serialization only. An

XML Schema would be able to more accurately represent HTML5  
conformance requirements. So: (a) No Doctype needed. (b) If one was  
present, it would at most be used to automatically load the referenced

DTD, but HTML5 doesn't have a DTD.

> http://www.oxygenxml.com/xhtml_editor.html

Supports either DTDs or schemas. Only appears to know about Schemas or

DTDs from a hardcoded list. So: (a) No Doctype needed. (b) Needs to be

updated for XHTML5 no matter what DTD syntax is used.

>
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.wst.webto
ols.doc.user/topics/tjprefs.html

Sounds like one would need to use the legacy-compat doctype for the  
auto-doctype-insertion feature, for HTML documents. It does not seem  
to care about the contents of the DOCTYPE declaration, just offers to

insert it automatically. Thus unclear how it would benefit from a  
version number.

> http://www.xmlmind.com/xmleditor/_distrib/doc/xhtml/xhtml_dtds.html

Looks like this is hardcoded to recognize only the XHTML 1.0 DTDs as  
XHTML documents. An HTML5 DTD bearing a version number would be just  
as unrecognized as "<!DOCTYPE html>" or no DTD at all.

> and a few more. Since there is substantial deployed
> infrastructure that knows about DOCTYPE-based
> editing and conformance validation, why add something
> that doesn't match reality?

DTD-based validation can't come even close to validating HTML5.

> The problem with the root element version parameter is
> that it can't as easily be used by a generic editor.

All of the editors in this set that are truly generic and which care  
about the DTD contents seem to support manual association of a DTD,  
and support XML Schema as an alternative.

Regards,
Maciej
Received on Monday, 1 March 2010 02:44:01 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC