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

On Feb 28, 2010, at 11:38 AM, Larry Masinter wrote:

> 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, I tried to read up on what "WAB Cluster" and UWEM actually are. As  
far as I can tell, UWEM is not a formal regulation. Rather, it is a  
methodology for applying WCAG, with a future planned grant of a "mark  
of quality" for passing these tests. It seems to me that there is a  
direct path from updating WCAG to an update in these guidelines.

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

Thanks for the example. I think the problem with this specific  
guideline is that it does not allow aria-describedby as a way to give  
a long description. This should be fixed regardless of HTML version. I  
don't think making the guideline depend on declared HTML version would  
be a helpful solution.

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

I am saying that. It's definitely not valid HTML4.

> And that no valid HTML5 is valid HTML4?

I'm not saying that, because HTML5 allows HTML4 strict mode doctypes.  
I believe that there are some documents that are both valid HTML5 and  
valid HTML4. However, validators are allowed to validate any document  
with an HTML4 or XHTML1 doctype against HTML4 or XHTML1 respectively.

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

Indeed legacy doctypes are allowed, and they would enable making  
documents that validate as both HTML4 or HTML5. I don't think that  
conflicts in any way with what I said.

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

It's not true that <!DOCTYPE html> is an indicator of HTML5  
specifically - it could be an indicator of future versions. But it is  
definitely an indicator of not being HTML4. Inclusion of an HTML4  
DOCTYPE is definitely an indicator of being HTML4. Though unlike any  
previous HTML version changeover, it is possible for a conforming  
HTML4 document to also be a conforming HTML5 document.

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

If an HTML4 construct is noncomforming HTML5, that does not prevent  
you from validating as HTML4. The workflow could simply call for  
conformance checking as HTML4. The only way this would conflict with  
standards is the possibility that it may be invalid to send HTML4 as  
text/html.

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

My experience is that a one-dimensional version indicator is a poor  
match for rapid evolution.

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

Can you cite some examples of DOCTYPE being used in the past to solve  
the kind of problem you are concerned about here? When I say "engineer  
a solution" I mean design a mechanism for indicating versions that can  
avoid this type of problem, write the spec language for it, deploy the  
change in validators and other tools, etc. I am not assuming that  
DOCTYPE is the best solution, or even on balance better than nothing,  
just because it has been used in the past. But even if it is, it would  
still require changes in many places to adopt your proposal.

>
>> 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 HTML6 makes something invalid that was valid HTML5, and all valid  
HTML5 doctypes are also valid HTML6 doctypes, then how

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

You specifically said "no DOCTYPE to look at" was the problematic  
situation. If you want to generalize to lack of any version indicator:

- As far as I can tell, Atom has no in-band format version indicator.  
There is a namespace URI but no indication of intent to change it for  
future Atom versions.
- RSS does have an in-band version indicator, but it is rarely used in  
the wild, is not present for all versions of RSS, is often wrong, and  
does not actually distinguish all incompatibly different versions. In  
practice clients must guess the RSS version by sniffing.

 From the point of view of a consumer of syndication feeds, I would  
say the Atom approach to versioning has been much less problematic.  
Are you aware of problems caused by Atom's lack of a format version  
indicator?

XForms does have a version attribute, but it does not act as a per- 
document format version identifier. It may appear separately in  
multiple places, it provides a list of versions, and XForms processors  
are required to abort processing of that fragment only if they do not  
understand any of the listed versions. As far as I can tell it is not  
intended as a hook for version-specific conformance checking or  
evaluation. It is a very different concept of versioning than what  
you've proposed for HTML.

Regards,
Maciej

Received on Sunday, 28 February 2010 20:41:37 UTC