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

ARC updated to latest syntax doc, WD feedback

From: Benjamin Nowack <bnowack@semsol.com>
Date: Mon, 25 Feb 2008 21:52:15 +0100
To: public-rdf-in-xhtml-tf@w3.org
Message-ID: <PM-GA.20080225215215.268D3.1.1D@semsol.com>

Hi all,

the latest ARC2 revision (2008-02-25)[1] has an updated RDFa extractor
which passes all approved test cases (I think). I've also updated the
extractor[2] linked from CrazyIvan. For some reason, I get a FAIL on 
some tests there, although I'm pretty sure the extractor is compliant. 

I live-logged[3] my way through the spec, which might be helpful as
feedback on the WD (warning: it's a little tongue-in-cheek and/or 
impatient here and there). I also only looked at the processing 
instructions, w/o really reading anything else of the spec. Here is a 
short (chronological) summary for (slightly) better readability:

11:19:14   * there are almost twice as many steps now, compared to the 
  previous spec. I would've expected a simplified final parsing process.

* step 9 is missing

* CURIE is not a valid abbreviation for "compact URI", should be cURI, 
  or CURI, no? or do I need Marie Curie capabilities to spot the E? ;)

* steps 1-6 seem fine to me, easy to follow

* step 7 seems to require a [new subject] in order to create a triple.
  This is not explicitly mentioned in the intro sentence. (this is 
  different from step 6, which explicitly says "none of this ... if 
  there is no [new subject]")(nitpick)

* step 8: fine to me

* step 10: understood, I guess it's identical to the previous spec version

* hmm, "once the triple has been created". There can be multiple, so maybe
  s/the/a/, i.e. *any* XMLLiteral object stops recursion (as I understand 

* step 11: "using the rules described here". What exactly does *here* refer
  to? step 11, or the whole process sections

* hmm, the distinction between the passed-in context, the current context, and
local variables is a bit confusing, I just used the passed-in context and
overwrote it's values while I was making my way through the process. That
worked fine in the prev. spec, but is apparently not correct now

* hmm, I fail to grok the text in the blue box in step 11

* "the final step (step 12, below) involves returning a flag. If the flag is
true, then incomplete triples are completed in the next step (step 11)"

* I *am* in step 11, s/next/this/ in he last sentence?

* ok, I'll try to read it as "text correct, numbers wrong", then 12 is the
final step, and step 11 is actually step 10 and can point at step 11 as "next

* "after having recursed into the processing of descendants" (could this be 
said in simpler words?)

* ok, I've done step 13 (12) now, that was easy

* now back to 12 (11)

* the "not the local list of incomplete triples" hint is helpful, I would've
been confused again w/o it

 * in step 12, everything from the 3rd block sentence ("Note that if [new
subject] is a bnode, then ... during this step") should perhaps be moved to 
a separate block. The first 2 sentences tell what I should do, I had the
impression I had to add a bnode check for new subject here after reading on.

 * "if direction is not 'forward'": are there any other possible values than


17:45:37 * pass/fail 63/0

I had to tweak the processing rules to get there, though. Something seems to 
be incorrect (or confused me) in the context of processing incomplete triples:

* step 12: "If the [skip element] flag is 'false' ...": this condition should
be removed. Otherwise, a number of test cases don't get a PASS.


[1] http://arc.semsol.org/download
[2] http://arc.web-semantics.org/demos/rdfa_tests/extract.php?url=
[3] http://arc.semsol.org/community/irc/logs/2008/02/22

Benjamin Nowack
Received on Monday, 25 February 2008 20:52:24 UTC

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