W3C home > Mailing lists > Public > www-tag@w3.org > January 2013

Re: The non-polyglot elephant in the room

From: Michael[tm] Smith <mike@w3.org>
Date: Sat, 26 Jan 2013 19:28:04 +0900
To: www-tag@w3.org
Message-ID: <20130126102802.GK42246@sideshowbarker>
Kingsley Idehen <kidehen@openlinksw.com>, 2013-01-22 07:45 -0500:

> On 1/21/13 11:03 PM, Michael[tm] Smith wrote:
> >Kingsley Idehen <kidehen@openlinksw.com>, 2013-01-21 18:54 -0500:
> >
> >>Question with regards to what Content-type to use when  I serve HTML5 via my
> >>HTTP server to HTML and HTML5 user agents :
> >>
> >>1. When I embed Microdata I should indicate Content-type ___________ ?
> >>2. When I embed Microformats I should indicate Content-type ______________ ?
> >>3. ditto when I embed RDFa Lite ____________ ?
> >>4. ditto when I embed  RDFa ________ ?
> >>
> >>If all of the above should be text/html, then there is a burden for HTML5
> >>parser developers, and most will simply ignore XHTML5 (no matter how hard
> >>one tries to squeeze this into HTML via text/html).
> >I may be missing some part of your point about parsing, but if by parser
> >you just mean constructing a DOM, then none of those four introduces any
> >additional parsing requirements, right?
> I am referring to a parser that would have to produce RDF model based data
> from an HTML5 document comprised of fine-grained structured data islands via
> any combination of Microdata, Microformats, RDFa Lite, or RDFa.

OK, then I guess what caused my misunderstanding is that we have different
notions about what an "HTML5 parser developer" is.

But I don't think my understanding about that matters in the context of
this discussion of the Polyglot spec, and I don't want to beat this into
the ground -- especially because FWIW I already agree with your comments
about content-type squatting being a bad idea that we shouldn't be
promoting. At least as far as I also understand what you mean by
content-type squatting.

> >  I mean, any stock HTML5 parser
> >already handles them. Actually, I think most any existing HTML parser
> >already should too -- e.g., the HTML parser in libxml2. As far as parsing
> >goes, they're all just additional attributes that the parser doesn't need
> >to have any special knowledge about.
> Really? And you mean this all works with content-type: text/html .

I'm not trying to be daft but I'm not sure what you mean by "all this" and
"works". I think maybe it gets back to me having a much more limited notion
of what an "HTML5 parser" than what I think you may have.

If what you mean by the question "This all works with content-type:
text/html?" is what you described above about "producing RDF model based
data from an HTML5 document", then my answer is that I don't think
producing RDF model data from an HTML5 document has anything at all to do
with text/html as a content type, nor with the parsing behavior that's
actually defined in the HTML spec.

The text/html content type is defined by the HTML spec, and the HTML spec
says nothing at all about producing RDF model data. Nor does the Microdata
spec -- which could logically just be included are part of the HTML spec
itself (and is in fact just another section in the WHATWG HTML spec)
without requiring any changes to the meaning of the text/html content type,
or changes to the definition of HTML parsing behavior in the HTML spec.


Michael[tm] Smith http://people.w3.org/mike
Received on Saturday, 26 January 2013 10:28:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:51 UTC