Re: thoughts on reviewers' comments

Ben Adida wrote:
> 
> 
> 
>> * Section 5.5, Rule 9 (and also the last two paragraphs of Section
>> 6.3.1.3): this is not a comment, but a question: must the parser descend
>> recursively when a non-XML literal has been created by concatenating
>> text nodes? I couldn't find a test case for this. In other words, I'm
>> not sure which should be the expected outcome of parsing the following
>> mark-up:
>>
>> <p about="http://dbpedia.org/resource/Albert_Einstein">
>>   <span property="foaf:name" datatype="">
>>      Albert
>>      <strong property="foaf:familyName">Einstein</strong>
>>   </span>
>> </p>
> 
> This is an interesting one. I'm torn on this issue. I think we should 
> still parse down the tree no matter what, I don't think a change in data 
> type should change the state of parsing.
> 

At the moment, the processing rules say:

- if a @property is used without a @content, then
 - the entire subtree is the value of the @property
 - the recursion stops at that point, ie, no further
 parsing is done
- this is independent of the value (and indeed presence) of @datatype.

So in the case cited by Diego the property value will be "Albert 
Einstein" (according to the current spec).

I am a bit uneasy to base the decision on further recursion or not based 
on the value of @datatype, I must admit; you seem to say the same... But 
this means that

<p about="http://dbpedia.org/resource/Albert_Einstein">
  <span property="foaf:name">
  Albert
  <strong property="foaf:familyName">Einstein</strong>
  </span>
</p>

Would yield the XMLLiteral _plus_ the recursed values, too. And that 
leads to the issue we had with that a long time ago: what happens, for 
example, to a <pre> somewhere down the line?

<p about="">
   This is an example for the correct usage of @property in RDFa
  <span property="ex:ample">
  <pre>
    <span property="what:ever">here</span>
  </pre>
  </span>
</p>

Surely you do not want the content of <pre> to be interpreted...

My proposal is to leave the spec as is unless there is a really, really 
compelling use case to reopen the whole argument:-)

> 
> Ed's comments [2]:
> 
>> perhaps pointing at the reference implementation would help people
>> like me?
> 
> I don't think we should have *one* reference implementation: we'd have 
>  to all review it deeply and live with whatever bugs we miss as "part of 
> the spec." Spec'ing via the test cases seems best.
> 

+1


>> Is non-XHTML RDFa discussed in any other documents that would be worth
>> linking to here?
> 
> I would vote for no forward pointers in our spec, so we should clarify 
> this language.
> 

I agree

>> 5.2
>>
>> Is it worth mentioning that 'direction' needs to be captured in the
>> list of incomplete triples?
> 
> My implementation keeps track of rel and rev separately, so this is a 
> useful comment I think.
> 

I would leave that to Mark... but, indeed, my implementation does not 
use this 'direction' either. Although I mix up the incomplete triplets 
for @rev and @rel, I store them at a temporary place and put a None 
value to the missing resource's place. I then complete that one by 
exchanging it against a real resource and then store it in the final 
triple store.

>> -- 5.5.5 Is the issue with Chained bnodes with no real statements 
>> captured as an Issue in the SWD Issue Tracker?
> 
> I don't think it needs to be: the same useless comments can be written 
> in RDF/XML, so if people want to write them.... why not parse them?
> 

I think I commented that before, ie, that this remark (attributed to me) 
seems to be moot with the new setup... Ie, I agree with you!

Ivan

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf