Re: ARC updated to latest syntax doc, WD feedback

Hi Benjamin,

Great review...thanks.

>  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.

Thanks. The idea of the section _prior_ to the processing section is
to explain some of the concepts, such as chaining. The idea of the
section _after_ the processing section is to go into more detail on
the steps described--a kind of 'annotation'.

So if there are gaps after reading all three sections, then we do need
to correct them.


> 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.

In the main this is because I broke quite a few steps into more
detailed versions of themselves after a number of comments. Also,
there were a couple of places where the steps were just plain wrong,
and would not have been sufficient to provide the functionality we
needed, so extra steps had to be added.


>  * step 9 is missing

There must be a mark-up error, since all lists use <li>. But
thanks...well spotted!


>  * 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? ;)

You are not the first to say that. Bridges and streets have been named
after people who have made far less contribution to humanity than the
CURIE family did. I'm not in a position to name a bridge after them,
but I can at least name a rather modest software technique (and
forthcoming specification) for them.


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

Ok.


>  * 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)

The [new subject] is actually set in step 5. When in step 6 we say "if
there is no [new subject]", we mean "no [new subject] set in the
previous (fifth) step. The [new subject] property is listed in section
5.3.

Would you mind looking again at this and saying what aspects of this
could be tightened up to make it clearer? (Or were you reading too
quickly? ;))


>  * step 8: fine to me

Ok.


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

Pretty much. The wording on child text nodes should be clearer in this
version, though.


>  * 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
>   it)

Yes...good point. Thanks.


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

It's recursive, so it's the entire processing sequence. If I added
something like "beginning again at step 1", or something like that,
would that make it better?


>  * 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

No...that's right, and it took a lot of work to fix. :(

The problem arose when one of our very talented reviewers asked when
the 'incomplete triple' list should be reset. This led to the
discovery that if you just overwrite the contexts (including resetting
the list of incomplete triples), then there are many situations where
you start to get incorrect results on siblings.

The major change to solve this was to complete the triples _after_
doing the recursing. This had a couple of other benefits, and
generally seems to be more robust.


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

It's an 'RDF thing'. :) If you have a statement where the object is a
bnode, and that bnode is not used in any other statements, then it's
pretty meaningless. It's a real edge case, and we were originally
going to just ignore it, but as a by-product of the fix that I just
described (postponing the completion of hanging triples until after
the recursion) it turned out you could actually fix this minor
annoyance.

So now, if an author does this:

  <div about="a">
    <div rel="b" />
  </div>

no triples will be generated. (Before we generated a triple with an
object of a bnode.)

Does this make any more sense? Do you have any suggestions on how the
wording could be improved? Or is it simply that it is the wrong place
to start trying to explain things. (I.e., we should move it out of the
processing steps.)


>  * "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
>  step"

Yes...you are right that the numbering has gone up the spout.


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

"But no simpler"? :)

I guess...any suggestions?


>  * 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

Good.


>   * 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.

By "the first 2 sentences" do you mean before the blue block? If so,
are you saying that effectively that's clear enough, and to try to add
the point again in the blue block is confusing?


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

No. It's essentially an 'else' statement, but using a test. (It just
shows that I'm unable to escape years of programming in assembler...if
ever we had two conditions A and B, we'd always test for A and not A,
so that you had a fallback.)

I guess we could change this if people think it's confusing.


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

Hurray!


>  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.

Which ones?

Not having this rule was a major flaw before, as pointed out by Ivan,
Ed and Diego. If we don't have this rule then all of the processing
rules were falling apart in situations like this:

  <div about="a">
    <div>
      <div rel="b">
        <div>
          <div resource="c" />
        </div>
      </div>
    </div>
  </div>

(The previous rules were often completing all the triples on the empty
elements.)


>  HTH,

Very much so...thanks.

Regards,

Mark

-- 
  Mark Birbeck

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.x-port.net | http://internet-apps.blogspot.com

  x-port.net Ltd. is registered in England and Wales, number 03730711
  The registered office is at:

    2nd Floor
    Titchfield House
    69-85 Tabernacle Street
    London
    EC2A 4RR

Received on Monday, 25 February 2008 21:40:25 UTC