- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 22 Jan 2013 07:45:50 -0500
- To: "Michael[tm] Smith" <mike@w3.org>
- CC: www-tag@w3.org
- Message-ID: <50FE89FE.5000902@openlinksw.com>
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. > 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 . > > --Mike > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 22 January 2013 12:46:13 UTC