Re: Issues with TC 107-109...

Manu,

for what it is worth, pyRdfa does exactly what librdfa does, ie what 
your sparql tests do. This means that your and my reading of the 
processing steps are identical... And Ben gave a good explanation for 
something that is really really a tiny corner case...

My question is different. I am not sure test #109 and and #108 are 
fundamentally different (except for one more level). In other words, if 
an implementation passes #108, it will pass #109, too, wouldn't it? If 
so, then #109 might be superfluous...

Ivan

Manu Sporny wrote:
> TCs 107-109 have been written to match what I believe the current
> processing rules state. librdfa was updated and the triples that are in
> the SPARQL for TC107-109 is what I got... however, I don't think this
> was our intent.
> 
> The issue has to do with step #10 of the processing rules - the list of
> incomplete triples being completed only if a new subject is found. This
> hurts the use case that was the main motivator for not "garbage
> collecting" bnodes: "What happens if somebody wants to build their
> triples up one-by-one?".
> 
> So this case:
> 
> <div about="#me">I know
>    <div rel="foaf:knows"></div>
> </div>
> 
> wouldn't generate a triple until you did this:
> 
> <div about="#me">I know
>    <div rel="foaf:knows">
>       <div rel="foaf:knows"></div>
>    </div>
> </div>
> 
> Which is fine, I guess - but I thought we wanted both to generate triples?
> 
> -- manu
> 

-- 

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