W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > September 2011

Draft response to ISSUE-105: @itemref support

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 13 Sep 2011 21:54:50 -0400
Message-ID: <4E70096A.406@digitalbazaar.com>
To: Jeni Tennison <jeni@jenitennison.com>
CC: RDFa WG <public-rdfa-wg@w3.org>
Hi Jeni,

We discussed supporting something like @itemref (ISSUE-105) two calls ago:

http://www.w3.org/2010/02/rdfa/meetings/2011-09-01#ISSUE__2d_105__3a____40_itemref_attribute

A number of concerns came out of that discussion that we wanted to run 
by you before closing the issue.

The biggest technical issue was that supporting something like @itemref 
makes it incredibly difficult to implement in SAX-based processors like 
librdfa - which is what raptor/redland uses. Until this point, one could 
do a one-pass RDFa processor implementation. While all of the points 
made about making authoring easier than implementation still hold, the 
benefit of having something like @itemref is questionable. In short - we 
have not seen a single, real-world use case that would greatly benefit 
from the feature.

If we wanted to support @itemref in SAX-based processors - we'd have to 
implement a multi-pass processor /or/ store a large amount of state 
information (basically every element with an @id attribute) for a 
one-pass processor. This impacts the speed and memory footprint on RDFa 
processors. Speed and memory footprints are important when performing 
large-scale crawls or implementations in consumer electronic devices. 
So, there is a fairly large trade-off for processing speed or memory 
footprint for an exact implementation of @itemref in SAX-based processors.

Granted, the feature may make certain types of markup scenarios a bit 
easier to author, but duplicating information via @itemref can also be a 
sign that you're doing a bad job of modeling your data. Since Microdata 
attempts to hide the fact that it is expressing a graph of information 
in JSON, at times it is necessary to copy sub-trees of information into 
the JSON representation. This is one of the reasons why @itemref exists 
- to duplicate information in the JSON object.

Typically, an RDFa author would just identify the duplicate information 
using @about and point to that subject in all of the objects that refer 
to the information.

One idea that surfaced during the discussion was that we could support 
something @itemref-like by allowing multiple values in @about. We had 
discussed supporting this at one point in RDFa 1.0's development - but 
we decided to forgo the feature as it can be incredibly complicated to 
explain to authors and there were no use cases that were compelling 
enough to reduce the implementation complexity concern to an acceptable 
level for the Working Group.

So at this point, we need a compelling use case that would outweigh the 
fairly large implementation burden for a feature like @itemref. We are 
also very concerned that allowing multiple subjects in @about would be 
very confusing to authors.

What are your thoughts on this Jeni? @itemref is helpful in a few 
scenarios, but it seems as if the trade-offs are not worth it to the 
Working Group. Do you have anything else to add? If there is no new 
evidence, the WG will probably close the issue due to the technical 
complexity and the lack of compelling use cases.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Building a Better World with Web Payments
http://manu.sporny.org/2011/better-world/
Received on Wednesday, 14 September 2011 01:55:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:17 GMT