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

@itemref-like feature in RDFa+HTML5 (tracker: this is ISSUE-144)

From: Ivan Herman <ivan@w3.org>
Date: Mon, 5 Nov 2012 09:40:19 +0100
Cc: Martin Hepp <mfhepp@gmail.com>, Dan Brickley <danbri@danbri.org>
Message-Id: <88DDC97D-6968-40E1-B005-0F6C56D34C24@w3.org>
To: W3C RDFa WG <public-rdfa-wg@w3.org>
Guys,

I am currently at the airport, so do not expect me answer right away (I am on a plane to Boston in about an hour). 

Here is my take on this: there may be a technical approach to do something similar (see below), I am still undecided whether to do so.

The technical approach:

I see two issues with an @itemref-like feature in RDFa:

1. At this stage I would be very reluctant to modify the core RDFa processing steps to include this facility. We have seen in the past that modifying the process is very tedious, resource intensive, and error prone. We have gone through that for the @inlist feature (request from Jeni and others) and the modification of the @property semantics (on request of schema.org). It would also raise eyebrows in the sense that the core processing steps are part of a recommendation, and modifying those processing steps in a host language is a bit tricky spec-wise.

2. There is one major difference between microdata and RDFa that comes into play here. In RDFa, there is _always_ a default subject, whereas this is not the case for microdata. This means that the 'target' of @itemref is not interpreted in microdata (unless there is an explicit @itemid) whereas it is in RDFa unless some special 'shield' is added.

However. I can look at the @itemref feature as a macro. Ie, I _define_ a macro somewhere, and I refer to that macro verbatim elsewhere. No variable processing, just textual copy-paste, conceptually. I can translate that into DOM tree manipulations that can be done as a pre-processing step prior to the full RDFa processing (we had this approach before). 

Along those lines, the way one could define this as follows (I just came up with attribute names, we can discuss the exact names later if we decide to go down that line).

1. Introduce the @macroid attribute. What it does is to assign and 'id' to the subtree starting with that node for RDFa processing, and, conceptually, 'unparents' it from the original DOM tree, ie, removes it from the tree.

2. Introduce a @macroref attribute. What it does is that it _replaces_ the DOM subtree at that point with a copy of the subtree defined by @macroid='id'

In practice, here is how it can be used:

<div macroid="id">
  <p property="p1">foo</p>
  <p property="p2">bar</p>
</div> 

...
<div resource="r1">
  <p property="q1">Bla 1</p>
  <link macroref="id"/>
</div>
...
<div resource="2">
  <p property="q2">Bla 2</p>
  <link macroref="id"/>
</div>


From an RDFa processing point of view, this would be equivalent to:

...
<div resource="r1">
  <p property="q1">Bla 1</p>
  <div>
    <p property="p1">foo</p>
    <p property="p2">bar</p>
  </div> 
</div>
...
<div resource="2">
  <p property="q2">Bla 2</p>
  <div>
    <p property="p1">foo</p>
    <p property="p2">bar</p>
  </div> 
</div>

Note how the <div macroid="id">...</div> has disappeared from processing and the <link> has been replaced. The <link> element comes in handy here. Note also that there is no notion of macro variables, nested macros, or anything of the sort; and we should not go down that line. Just the simplest possible features.

Implementation of this requires some DOM processing, but may not be very onerous (and some XML processors may have a cloning operation already). That being said, it is relatively expensive, because it requires, conceptually, two more DOM traversals before the RDFa processing. This makes it hard to implement on a streaming environment; I am not sure how problematic that is. In our user cases the DOM trees are small (a typical Web page is not that large as a DOM tree, although some complicated embedded SVG processing may be different). (Note, b.t.w., that the microdata @itemref has probably the same issues v.a.v. streaming.)

Thoughts? I know Niklas (and Toby, if he still listens) will come with all the possible corner cases and issues;-) but that is fine. We should, in a sense, ignore those and make it clear that this is not the place for users to get tricky...

Cheers, talk to you from Boston...

Ivan

----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Monday, 5 November 2012 08:40:44 UTC

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