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