Re: New HTML/XML Task Force Report published

Robin Berjon <robin@berjon.com> writes:

> On Mar 22, 2011, at 19:50 , Norman Walsh wrote:
>> I've just published the first draft of any actual substance:
>> 
>>  http://www.w3.org/2010/html-xml/snapshot/report.html
>
> Thanks! Here are some quick notes:

Thanks for your comments, Robin.

>   • if such content was accessible -> were accessible
>
>   • impedement -> impediment
>
>   • "Given that the world at large is unlikely to adopt polyglot
> markup as the standard way to encode all HTML documents, this solution
> may have limited applicability." I think that we can be less careful
> and safely say that it has limited applicability.

Ok. I tried to be a little less careful.

>   • The XML consuming HTML use case should really point to the Infoset
> coercion part of HTML:
> http://dev.w3.org/html5/spec/the-end.html#coercing-an-html-dom-into-an-infoset
> (Probably towards the end where the solution is outlined).

Done.

>   • "As the HTML5 ecosystem grows, it's easy to imagine a day when
> HTML5 toolchains are widespread and popular." I think we're there
> already :) I'd just go with "HTML tool chains are widespread and
> popular."

Ok. What tools besides browsers and Henri's validator exist that
accept HTML5 as input?

>   • "These rules will not always produce the same DOM that an XML
> parser would have produced." In fact, these rules will rarely produce
> the same DOM. (Should we be saying Infoset? Or don't we care?)

I made that more explicit. I also added a note to the introduction
trying to gloss over the various possible distinctions we could make
between Infosets and DOM in particular and any abstract or concrete
representation of a parsed document.

>   • I think that the reading XML in an HTML environment use case is a
> bit weird. At the very least "translating XML to HTML5" would need at
> least some description of what that entails. I'd tend to think that
> "parse it with an XML parser, then you have a DOM that can be used in
> HTML settings" is more realistic. HTML environments do in general tend
> to have XML parsers around (e.g. DOMParser). Which ones don't?

I added a note that such a translation may be difficult :-) and the
possibility that using an XML parser might also work.

>   • "When the HTML5 parser encounters unfamiliar markup, it assumes
> that such markup is an erroneous attempt to generate or author valid
> HTML5." I'm not sure that the parser can be said to being "authoring"
> content. We might get into tricky lawsuits with that one.

Fixed.

>   • "result in a DOM representation that can differ more-or-less
> arbitrarily from the DOM" I don't think that the differences are more
> or less arbitrary — but I'd say that it can differ "more or less
> radically".

Ok.

>   • "by specifying the content type “application/xml”." There's a
> markup error here (type is <tt> for some reason). Also, I'd add
> something to the effect of "or any other applicable media type". For
> instance, SVG Web, which uses this technique, places SVG in script
> elements with type image/svg+xml.

Fixed.

> Do we have a plan for reaching some kind of collective conclusion?

We have a goal to do that, but not yet a plan :-/

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com