LC comment: Don't discriminate against "useless" triples

These are personal comments, sent separately for the benefit of the 
tracking system


The Last Call specification mentions "useless" triples and defines rules 
whereby they can be omitted ("garbage collected", as referred to on the 
list). In algorithmic terms, the changes involved here were quite minor, 
only changing the order of a few steps in the sequence so that a small 
bit of processing occurs after the main recursion. BUT, this change is 
only minor for implementations that more-or-less follow the sequence in 
section 5.5 of the Last Call spec. For implementations work a different 
way, this change may introduce much more complexity. In particular, with 
XSLT 1.0.

Take this example from the spec:
<div rel="foaf:knows">
 <div rel="foaf:knows">
   <div rel="foaf:knows">
     ...
   </div>
 </div>
</div>

As recursive processing visits the outermost <div>, the difficult 
question that must be answered before moving along is whether (and how 
many) triples are to be generated. This turns out to be quite difficult 
to do. XSLT is Turing Complete, so I don't doubt whether it's possible. 
I doubt whether it is *reasonably* possible, without incurring huge 
execution time/space costs, or lots of stylesheet complexity in the name 
of a questionable feature.

BTW, I object to the description of triples such as the inner ones in 
the example above as "useless". To call them such is to second-guess 
document authors without good cause.

If, on the other hand, no attempt was made to omit "useless" triples, 
then the XSLT processing on, say, the outer div in the example above 
becomes relatively straightforward--it's easy to see that a triple must 
be generated. As an observation, I noted on 3/28 that the latest XSLT 
from Fabian preserves triples in a case similar to the above. This is 
reasonable and should be the way of things.

(There may also be some advantages to having the procedural description 
of RDFa processing be tail-recursive, which is a likely side-effect of 
the change this comment requests. However, even if this is the case, it 
is a beneficial side-effect of this request,  not the main thrust.)

I couldn't find any test cases covering this situation. If there in fact 
aren't any, please create some (with the help of the community, of course).

Even if this change would be considered substantive and result in 
another Last Call, I still stand by it. It's important to get this 
right. I would not object to a shorter duration and/or more limited 
scope for a 2nd Last Call.

Thanks, -m

Received on Monday, 31 March 2008 04:40:31 UTC