[Bug 20707] Please add a Scope section per the qualification of the TAG's support for REC track publication

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20707

--- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to comment #2)
> (In reply to comment #1)
> >    * XML-based HTML tools or systems intended
> >      for the most general contexts of use cannot
> >      depend on polyglot input: for maximum flexibility
> > <ins>when creating polyglot markup with</ins> such tools,
> > <del>such</del><ins>the</ins> tools should use the technique of using an
> >      HTML parser that produces an XML-compatible DOM or
> >      event stream
> 
> The first part of the sentence is talking about tools that are *consuming*
> markup.

The problem is that, taken together, then *both* bullet points talk about
*consuming* markup. Because, when first bullet point talks about "controlled
environments", then it has in mind environements where both consumption and
output is XML. The second bullet point talks about "uncontrolled" environments,
in which it of course is the parsing that becomes the problem.

The problem with the focus on the parsing is that it builds on an idea from the
XML-HTML Task Force which assumes that the point with polyglot markup is to
create documents that can serve as food for an XML tool chain.

However, that is not the purpose. Being ready to be parsed by such tools is of
course one benefit of polyglot markup. But, actually, polyglot markup is more a
"HTML-parsing safe" format - a robust format which is guaranteed to survive a
XML toolchain with at more or less dubious HTML preparser

The other, important purpose of polygot markup is simply to survive Web
browsers’s parsing - the very basic rule that the DOCTYPE is required etc,
ensures that there no quirks-mode is triggered, and thus ensures that elements
are treated the same way by both XHTML and HTML parsers.

> I don't think that the TAG intended for these exact words to be used
> within the Scope section, but if it helps to clarify the intent, it would be
> better to say:
> 
>     ... for maximum flexibility, XML-based tools that consume
>     HTML should use the technique of using an HTML parser that
>     produces a DOM or event stream that can be consumed as XML.
> 
> Also, note the reference to 'authoring tools' in the first bullet point
> could encompass any HTML-generating tool, though it's not as strong as you'd
> like (suggesting providing polyglot output as an option rather than saying
> it *must* be produced).

1) Regarding my "*must* output polyglot markup", please replace it with
"outputs polylgot markup". The point I tried to make was that this spec should
not become a document that teaches good ways to produce HTML - in general. And
in particular, it is not this spec's task to tell authors how they can produce
something *other* than polyglot markup - such a thign only produces FUD (fear,
uncertainty and doubt).

2) This is not really meant as an argumetn against the TAG text, but in my
view, the spec is *already* a bit too concerned with explaining that "polyglot
is not for all". Because, yes, it is for all. It is for all that wants to
produce polyglot markup and have the benfits of that.

3) Regarding "authoring tools": Thanks for pointing that out. When I now reread
the first bullet point, I understand that "and for authoring tools" in fact
reflects what I myself has claimed earlier on in the debate. But the way I see
it, then e.g. a WYSIWYG authoring tool is more comparable to a "XML tool chain
with HTML parser" than it is comparable to a "controlled environment". (Well,
it depends on how the tool handles pre-existing markup, of course …)

4) Regarding your rephrasing of "for maximum flexibility" then it flows better
than the original text.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 20 January 2013 00:56:40 UTC