Re: ARC updated to latest syntax doc, WD feedback

On 25.02.2008 21:40:13, Mark Birbeck wrote:
>>  * 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.
LOL, OK. But then I'll use the French pronounciation from now on ;)

>
>>  * 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 6 explicitly mentions [new subject] as an entry condition. It also
closes with an additional blue "info block" that repeats this condition.
I think this info block could be removed.

In step 7 I'd follow the pattern from step 6 and start with :
[[
If in any of the previous steps a [new subject] *and* a [current object
resource] were set to a non-null value, they are now used to generate
triples:
]]

This might just be a personal preference, though.

>>  * 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?
Yeah, or maybe just *replace* the "using the rules described here" with
"(beginning again at step 1)"? You'd then get rid of the repeated "using"
in that sentence, too:
[[
... all elements that are children of the [current element] are processed 
(beginning again at step 1), using a new [evaluation context] ...
]]

>
>>  * hmm, I fail to grok the text in the blue box in step 11
>
>It's an 'RDF thing'. :) 
[...]
>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.)

I think it was more the (broken) numbers that confused me, i.e. the
pointers to other steps in the first paragraph in the box didn't work 
for me. I guess it's ok to keep it within the processing context.

>>  * "after having recursed into the processing of descendants" (could this be
>>  said in simpler words?)
>
>"But no simpler"? :)
>
>I guess...any suggestions?
hmm, not sure. "after having processed the descendants" would sound
more clear to me, even if it isn't as accurate. or just drop the whole
"after having recursed into the processing of descendants". And maybe
change the "forwarded to step 11", too? (sounds a bit like Basic-style
"GOTO 11"):
[[
This returned value is used in step 11 to determine whether to complete
any [incomplete triple]s.
]]

>
>>   * 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?
I'd perhaps try to visually separate instructions from notes/explanations, 
e.g. the step 12 box could be split into two boxes:
[[
The [list of incomplete triples] from the current [evaluation context] (not the
[local list of incomplete triples]) will contain zero or more predicate URIs.
This list is iterated, and each of the predicates is used with [parent subject]
and [new subject] to generate a triple.
]]
[[
Note that if [new subject] is a bnode, then the process of completion will only
happen if triples were created during the course of processing descendant
elements. Note also that at each level there are two, lists of [incomplete
triple]s; one for the current processing level (which is passed to each child
element in the previous step), and one that was received as part of the
[evaluation context]. It is the latter that is used in processing during this
step.
]]
Oh, I just saw that the explanations usually start with "Note" already. So,
alternatively, what about changing "Note that" to "<strong>Note:</strong>. 
I think that would be a nice (and sufficient) improvement readability-wise.

>>   * "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.
Not confusing, just triggered a scrollback to check.


>>  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?
Hmm, there is of course the possibility that I don't set [skip] correctly. 
These tests currently fail when I add the skip==false condition:

0033
0046
0048


Best,
Benji

--
Benjamin Nowack
http://bnode.org/

Received on Thursday, 28 February 2008 10:52:35 UTC