- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 13 Sep 2011 21:54:50 -0400
- 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 UTC