- From: Toby Inkster <tai@g5n.co.uk>
- Date: Mon, 15 Nov 2010 12:35:25 +0000
- To: Ivan Herman <ivan@w3.org>
- Cc: RDFa Working Group <public-rdfa-wg@w3.org>
On Mon, 2010-11-15 at 13:02 +0100, Ivan Herman wrote: > Actually, this may be an idea on the specification level, too. Why > don't we specify these things as a virtual DOM->DOM transformation in > the document, too? Ie, let us not touch the formal processing steps of > RDFa Core; rather, any host language could be defined by such > transformations (and possibly a default profile). That would suggest a > much cleaner separation specification-wise. I'd be happy with this provided that it doesn't lead to implementations being required to support XSLT. XSLT (2.0 in particular) is a pretty heavy-weight dependency. Perhaps something along the lines of: "Host language specifications SHOULD provide an XSLT transformation that may be used to transform a host language document into a document capable of being parsed as RDFa Core 1.1. Processing software MAY use this as part of a pre-processing step to handle the host language." The only problem with this -- and pre-processing in general -- is the XMLLiteral edge case. e.g. <feed xmlns="http://www.w3.org/2005/Atom" property="http://example.com/xml" datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral" ><entry /></feed> Should result in the following triple: <> <http://example.com/xml> "<entry xmlns=\"http://www.w3.org/2005/Atom\"></entry>"^^rdf:XMLLiteral . But if a pre-processor were used, might result in: <> <http://example.com/xml> "<entry xmlns=\"http://www.w3.org/2005/Atom\" typeof=\"\"></entry>"^^rdf:XMLLiteral . The XSLT needs to be pretty clever to avoid things like this. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Monday, 15 November 2010 12:36:11 UTC