Re: Section 1 of the New RDFa Syntax Draft ready for reviews

Hi Ivan,

> - HTML4 is not in XML, right? I just wonder whether the very DOM
> oriented processing steps would be appropriate. What seems to be
> relatively straightforward is an XHTML1.0+RDFa, the question is whether
> doing the corresponding DTD would be that easy.

I think XHTML+RDFa is easier to define...that's true. And in terms of
processing RDFa on a server, it's also slightly easier to implement
than HTML+RDFa, because you can use XML tools.

But a consequence of XHTML not being 'standard' across browsers, is
that there is no difference between implementing an XHTML+RDFa and an
HTML+RDFa parser.

This is because, although an enormous number of documents are created
as XHTML on the server, they are delivered to the client as
"text/html", which will switch the browser into HTML mode. So anyone
writing a client-side parser for XHTML+RDFa is almost certainly going
to have to write it so that it works in 'HTML mode'.

(Which is incidentally why I used the DOM idea to define the
processing, because it works with both HTML DOMs and XHTML DOMs.)

I'm not saying anything here about the original question -- I think
we'll get to the HTML+RDFa side when we're ready. I'm merely pointing
out that technically it's a no-brainer, because we took care to make
sure that this was so. As Shane says, the only piece missing to create
an HTML+RDFa Syntax is a way to set the prefix mappings. (And even
then, that's only because it seems odd to use the @xmlns mechanism in
HTML.)


> - The real issue is, however, HTML5. And that is only where a crystal
> ball would help:-)

Indeed. :)

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Tuesday, 29 January 2008 10:43:53 UTC