W3C home > Mailing lists > Public > public-rdfa@w3.org > May 2009

Re: HTML 4 Profile for RDFa

From: Laurens Holst <laurens.nospam@grauw.nl>
Date: Fri, 15 May 2009 00:00:52 +0200
Message-ID: <4A0C9494.2070304@grauw.nl>
To: Tom Morris <tom@tommorris.org>
CC: Philip Taylor <pjt47@cam.ac.uk>, Sam Ruby <rubys@intertwingly.net>, Shane McCarron <shane@aptest.com>, RDFa Community <public-rdfa@w3.org>, "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Tom Morris schreef:
> As someone who has written an RDF/XML parser, an XMLLiteral is stored
> by RDF libraries as a string that's just marked as an XML literal.
> So, if we had <span [...property/subject declaration...]
> datatype="rdf:XMLLiteral"><a href="http://example.org/">Bla bla
> bla</a></span>
> This would become in N-Triples, N3 and Turtle:
> _:somesubject ex:some property """<a href="http://example.org/">Bla
> bla bla</a>"""^^rdf:XMLLiteral

That can’t be true, you would lose namespace information. At the least 
xmlns attributes should be added to that serialisation.

On the topic of XML literals: it is obvious that RDFa in HTML content 
must be parsed with an HTML parser into a DOM. This parsing algorithm is 
defined in HTML5. From this DOM, HTML5 also defines an XML 
serialisation. So serialising any malformed markup into an XMLLiteral 
should be no problem, because the HTML parsing algorithm will have 
‘fixed it up’ into a well-formed DOM tree.

On a side note, I do not think putting serialised HTML into a string is 
a good idea, display of such strings will include markup unless some 
kind of content sniffing is done on the output, which is undesirable. 
Using the textContent in such cases would be much better.


Note: New email address! Please update your address book.

~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, student, Utrecht University, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com

Received on Thursday, 14 May 2009 22:01:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:43 UTC