W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > November 2010

Re: Atom 1.0 + RDFa 1.1

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>
Message-ID: <1289824525.9995.52.camel@ophelia2.g5n.co.uk>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:50 UTC