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

On Feb 27, 2010, at 7:58 PM, Larry Masinter wrote:

> Adam and Maciej:
>
> There's also Test 1.1_HTML_05 which tests explicitly for img@longdesc
> for images that "require a long description" although it does
> say "Fully automatable: no", it doesn't say "and any other method
> might also be used".
>
> But this is getting pretty far afield from the original subject,
> which was about versioning:
>
>  Are there any mandated or regulated tests for compliance with
>  laws, regulations or policies, where the test explicitly requires
>  something which is valid in HTML4, and isn't valid in HTML5,
>  or which might become invalid in the future?
>
> If you say "no, there are no such tests" or "such tests
> are unimportant and we don't take them into account", then we
> can go hunting through test suites looking for some, or
> for some people who care about them.
>
> It seems like you're picking on the examples and giving
> reasons why you think they aren't really examples, but
> not really answering whether you think there are NO examples
> and never will be.

I think the specific examples you cited don't support the argument you  
made. That's all I was looking to point out. I would not make the  
claim that there are no such examples.

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.

A few thoughts, though, on hypothetical examples of this kind of  
scenario:

1) It seems to me that documents with an HTML4 doctype can already be  
distinguished from ones with an HTML5 doctype. In fact, conformance  
checkers are explicitly allowed to defer to an HTML4 validator if they  
see an HTML4 doctype. 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. 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). But that problem  
is not resolved by changing the set of allowed DOCTYPE strings to  
include ones with an explicit HTML5 version indicator.

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. 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.

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.

>
> 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.

Regards,
Maciej

Received on Sunday, 28 February 2010 17:56:26 UTC