- 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