Re: Agenda Topic / Issue: Clarify the meaning of "ignore" with respect to attributes that have no legal value

Shane,

On 12 Sep 2009, at 14:09, Shane McCarron wrote:
> Jeni Tennison wrote:
>>
>> In the case of
>>
>> <p xmlns:ex="http://example.org/" about="http://example.com/"  
>> rel="ex:rel3">
>>    <span property="bogus:bogus" content="Content 3">
>>      <span about="http://example.net/">Test 3</span>
>>    </span>
>>  </p>
>>
>> by the same argument, we should create:
>>
>> Default graph:
>>   <http://example.com/> <http://example.org/rel3> _:a .
>>
>> Graph A:
>>   _:a bogus:bogus "Content 3" .
>>
>> To do this, the property attribute must be treated as "present"  
>> rather than as "not present" (ie as if the property attribute  
>> wasn't there).
> Well... this presumes that you are creating an alternate graph.  If  
> you want to do this in your implementation, you are free to do so.   
> A Conforming RDFa Processor is not required to do this.

Sorry, I wasn't clear. As I understood it, Mark's argument was (for a  
similar situation involving illegal rels) that you would want to allow  
a conforming processor to produce a triple from the illegal rel value  
(but in a separate graph) which made sense when coupled with the  
triple that all conforming processors *must* make in the default  
graph. And therefore, that the default graph must contain the triple  
with the bnode rather than a triple that skipped the bnode.

If you accept that argument when it comes to illegal rels (which you  
seemed to), I think exactly the same argument applies for illegal  
properties because of the effect they have on [skip content].

Hopefully Mark will be able to either make that argument more  
persuasively to you, or to explain why it doesn't apply in this case  
to me.

> As to the "basis" for my conclusion...
>
> Processing step 8 reads, in part:
>
> If however [current object resource] was set to null, but there are  
> predicates present, then they must be stored as [incomplete  
> triple]s, pending the discovery of a subject that can be used as the  
> object. Also, [current object resource] should be set to a newly  
> created [bnode];
>
> This means that while a bnode must be *named* at this time, the  
> corresponding triple would not be included in the default graph  
> unless the bnode is actually resolved by attaching it to something  
> else during the recursive processing of the child elements.

Right, and in this example there are two possible ways in which the  
hanging triple created during the processing of the <p> element can be  
attached. If the HTML was:

<p xmlns:ex="http://example.org/" about="http://example.com/"  
rel="ex:rel3">
   <span content="Content 3">
     <span about="http://example.net/">Test 3</span>
   </span>
</p>

then the hanging triple would be completed when the inner <span> was  
encountered, with the object being <http://example.net/>.

If the HTML was:

<p xmlns:ex="http://example.org/" about="http://example.com/"  
rel="ex:rel3">
   <span property="ex:prop" content="Content 3">
     <span about="http://example.net/">Test 3</span>
   </span>
</p>

then the hanging triple would be completed when the outer <span> was  
encountered, with the object being a bnode.

As far as I can tell, in order for the hanging triple to not be  
completed at all, when processing the outer <span> you would have to  
both set [skip element] to true (so that they're not completed in step  
10 of the processing of the outer <span>) and set [recurse] to false  
(so that they're not completed when the inner <span> is processed).

It would certainly be possible to have an illegal property value set  
[recurse] to false in step 9.


I'm sure that you understand the intention of the RDFa Task Force far  
better than I do. I'm only trying to (a) understand that intention  
myself so that rdfQuery is properly implemented and (b) help you  
understand where the spec doesn't seem to reflect that intention,  
especially since I know how hard it is to really *see* a spec when  
you've been involved in creating it.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Saturday, 12 September 2009 19:29:09 UTC