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

Re: Safe Subsets of RDFa

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Wed, 10 Nov 2010 14:04:18 -0500
To: Julian Reschke <julian.reschke@gmx.de>
CC: Toby Inkster <tai@g5n.co.uk>, "public-rdfa-wg@w3.org" <public-rdfa-wg@w3.org>
Message-ID: <E8740751-2480-4BD8-9C20-E0985609E0EF@kellogg-assoc.com>
One mechanism I've considered is to create a jQuery library that implements designed-in profiles through DOM re-writing. This way, I can remove dependencies on externally loading a profile I'm aware of, as an author, and it also allows me to address other issues of 1.0 vs. 1.1. It isn't a generalizable solution, but as an App writer, where I know the profiles I depend on, and have some control over the HTML markup, it seems like a reasonable solution.

I'm not aware of any JavaScript RDFa parsers that are up-to-date with RDFa 1.1 LC. That being the case, I'd end up re-writing CURIES and Terms in RDFa properties as necessary to be 1.0 compliant, but I'd rather not have to do that.


On Nov 10, 2010, at 9:57 AM, Julian Reschke wrote:

> On 10.11.2010 13:49, Toby Inkster wrote:
>> Both Google and Facebook seem to consume subsets of RDFa.
>> Some subsets of RDFa are safer to consume than others though, as this
>> Wiki page demonstrates:
>> http://www.w3.org/2010/02/rdfa/wiki/Subsets
>> I think it would be useful for this WG to publish as a note something
>> like the above, as guidance for people wishing to implement partial
>> RDFa processors.
>> Alternatively this could be added as informative guidance to RDFa Core,
>> but I think it would overcomplicate the spec.
> Hi,
> as somebody only occasionally watching: YES.
> I fear that the new profile feature introduces an indirection mechanism 
> that is likely to cause more confusion than XML namespace prefixes will 
> ever manage to, so identifying a subset of RDFa that can be processed 
> without having to consult an additional resource seems to be very much 
> needed.
> Best regards, Julian
Received on Wednesday, 10 November 2010 19:05:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:22 UTC