- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Tue, 12 Jun 2007 14:56:03 -0400
- To: <public-grddl-wg@w3.org>
- Cc: "Jeremy Carroll" <jjc@hpl.hp.com>, "McBride, Brian" <brian.mcbride@hp.com>
I am still working on specific, normative text changes to submit as a proposed solution to issue-dbooth-3 (ambiguity), and in trying to figure out what the least cost solution might be I have benefitted greatly from many private discussions with working group members that I have been able to reach by phone. However, today I stumbled upon another illustration of the problem that I thought might help to clarify one aspect of this issue more succintly. In issue-dbooth-3, I picked on indeterminate XInclude processing as a convenient *example* of the problem that can occur if the GRDDL transformation author is not permitted to indicate what processing should occur in producing the XPath Node tree from a given representation. Lest anyone think that this problem is limited to XInclude, here is an illustration of it in a very general but simple form. IDENTITY TRANSFORMATION PROBLEM As a GRDDL transformation author, I wish to write an unambiguous identity transformation, such that for any given representation R, served from URI U, the GRDDL result of the transformation is a single RDF assertion of the form: U myns:says R. At present, the GRDDL spec does not permit me to write such a transformation to produce correct results without ambiguity, because a GRDDL transformation is currently defined to take an XPath Node tree as its input, and does not permit my GRDDL transformation to indicate how the representation should be parsed into that XPath Node tree. OBSERVATION This aspect of issue-dbooth-3 would be relatively simple to fix by changing the definition of "GRDDL transformation" to take the representation as its input instead of an XPath Node tree. This would completely side-step the faithful-infoset issue (by leaving the choice of infoset up to the GRDDL transformation author), and would also allow GRDDL transformation authors to benefit from the XProc spec when it is finished, and benefit from any TAG decision on the xmlfunctions-34 issue when that is resolved. David Booth, Ph.D. HP Software +1 617 629 8881 office | dbooth@hp.com http://www.hp.com/go/software Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
Received on Tuesday, 12 June 2007 18:56:19 UTC