W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > August 2008

Re: Help with test case 105 and 106

From: Ben Adida <ben@adida.net>
Date: Sun, 03 Aug 2008 22:22:26 -0700
Message-ID: <48969212.9040902@adida.net>
To: Micah Dubinko <Micah.Dubinko@marklogic.com>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>

Micah Dubinko wrote:
> The @href completing the triple, for
> <> <dc:creator> 
> <http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/ben.html>

So, if you have a situation where the @href completes the triple, then 
you would definitely *not* get the triple:

   <> dc:creator _:blanknode

right? The hanging triple cannot both be completed by a blank node 
caused by the inner @rel, *and* jump over to the inner @href, too.

This should begin to point out why, once you have

   <> dc:creator _:blanknode

there's really nothing you can do with that inner @href anymore.

> Thanks, this is helpful. I'm with you up to this point. The next question is
> why doesn't the @href complete the triple?

The point I made above effectively argues that a missing @rel is not 
quite the same thing as a @rel with a non-CURIE value. The @rel 
attribute is still there, and it causes hanging-triple completion before 
its value (CURIE or not) is ever considered.

Consider the test case again:

  <div about="" rel="dc:creator">
     <a rel="foobar" href="ben.html">Ben</a> created this page.

If "foobar" were a reserved word, this would yield:

   <> dc:creator _:blank
   _:blank xh:foobar <ben.html>

But since "foobar" is not a reserved word, the second triple disappears. 
The first one stays as is, otherwise we'd lose the ability to add 
reserved words in the future, as future parsers would have to generate 
altogether different triples.

We want a situation where, with new reserved words, we only *add* 
triples, we never take any away.

Received on Monday, 4 August 2008 05:23:05 UTC

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