- From: Micah Dubinko <mdubinko@yahoo-inc.com>
- Date: Sun, 30 Mar 2008 21:36:24 -0700
- To: RDFa <public-rdf-in-xhtml-tf@w3.org>
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