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

Just to remind everyone of the context:

http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html
is a change proposal for ISSUE-4, which notes:

  A  PublicIdentifier SHOULD NOT be used unless the content 
  is being managed in a controlled environment where the intended
  version is known, and the document is well-formed; this might be 
  the case in some XML-based workflows and editing environments, 
  or content management systems and other production workflows.

My point here is that production and maintenance of web
sites in regulated environments, where passing testing
of conformance to accessibility is mandated, is one such
"controlled environment".

> So could there hypothetically be regulations that specifically
mandate  
> an HTML4 construct that is not valid HTML5? Maybe. It's hard for me
to  
> evaluate their importance as a use case without concrete examples.  
> It's also hard for me to say what, if any, remedies we should apply.

To repeat the example once more (sigh):

http://www.wabcluster.org/uwem/tests/

look at places which reference "@summary" and "@longdesc",
including Test 1.1_HTML_05, which tests explicitly for
img@longdesc for images that "require a long description"; 
although it is not "Fully automatable", the test does not
allow any other method.

Do you think this example is "hypothetical"?
It seems to have been produced by a broad community.

> 1) It seems to me that documents with an HTML4 doctype can already
be  
> distinguished from ones with an HTML5 doctype. 

Are you saying <!DOCTYPE html> isn't valid HTML4? And
that no valid HTML5 is valid HTML4? 

And in the most recent editor's drafts, legacy doctype
strings are allowed in HTML5, so I don't think what you're
saying would be true any more, if it was ever.

> So examples of requiring HTML4 constructs that  
> are invalid HTML5 would not be helped in any way by adding an
explicit  
> version indicator to HTML5.

This was based on the false hypothesis that
lack of a DOCTYPE publicid was some kind of HTML5 version
indicator, or inclusion of a legacy obsolete DOCTYPE
publicid was a HTML4 indicator, which I don't think is true.

>  Now, there may be other problems with  
> this, such as not allowing HTML4 to be sent as text/html (depending
on  
> what ultimately happens with our IANA registration). 

I don't think the MIME type has much to do with conformance
testing of HTML in regulated workflows. Could you explain?


> 2) There are surely no examples that we can point to now of
requiring  
> HTML5 constructs that will be illegal HTML6. Maybe such examples
will  
> come up in the future. But then I would think about Adam's argument

> about the present expected value of pre-emptively solving a problem

> that may happen many years down the road.

Taking into account today future extensibility and evolution
is completely appropriate, especially in areas that are under
active development, and appropriate for enabling future
rapid evolution of the web.

>  i would also weigh the  
> likelihood that we can engineer a good solution to a hypothetical  
> future problem today, compared to what we could do once the problem

> arises.

HTML has traditionally had a versioning mechanism, which
the HTML5 draft has removed, over some objections. The
change proposal I submitted is intended merely to reinstate
this previously removed HTML4 feature of a DOCTYPE version
indicator. The problem is neither hypothetical -- there are
ample examples in the past, and current examples today --
and the suggestion that any "engineering" is necessary
to reinstate the existing DOCTYPE versioning mechanism
requires more justification. What do you think needs
to be "engineered"? The DOCTYPE change proposal requires 
no browser changes at all.

> 3) Lack of explicit version indicator in HTML5 does not preclude a  
> future Working Group from adding one to HTML6. But it will give them

> the option not to, if they see no need to distinguish from HTML5.

That option is there whether or not the doctype change proposal
http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html
is adopted.


> If, on the other hand, you agree that there are, or are likely
> to be, any examples of this, then we can talk about how
> the suggestion that the testing be "version specific" might
> work in the situation when there is no DOCTYPE to look at.

> We also have some practical experience with situation where there is

> no DOCTYPE to look at, namely many recent XML languages. Specific  
> examples of user-facing markup languages that do not use a doctype  
> declaration at all include SVG 1.2, XForms 1.1, Atom, and RSS 2.0.
Do  
> we know of any examples of actual problems caused by any of these  
> languages not having a DOCTYPE at all? That would be more compelling

> than hypothetical problems.

The UWEM example isn't hypothetical.

All of your examples have version indicators:
SVG has a "version" and a "baseProfile".
XForms has a "version"
Atom has both a namespace and a version
RSS has a version parameter

The ISSUE, ISSUE-4, is about versioning. DOCTYPE is a proposal.
The DOCTYPE has been the traditional way of supplying version
indicators in HTML, and is what is available in HTML4 and earlier
versions of HTML. Switching to a different mechanism for providing
an in-band global version indicator for text/html was in my
change proposal.

If someone wants to write a different change proposal which
introduces a HTML version parameter somewhere else, I would
likely be willing to support that as well. 


Larry
--
http://larry.masinter.net

Received on Sunday, 28 February 2010 19:39:02 UTC