Re: [issue-dbooth-3] Identity transformation

It is unclear why you think GRDDL should be able to do this.

Yes this is a potential useful function in some applications.

But wanting triples of the form:

U myns:says R.

where I take R to be a sequence of bytes, corresponding to the XML 
document that GRDDL is dealing with, basically lies outside the GRDDL 
scope, since GRDDL *is* built on top of XML, and hence accesses the 
representation after at least some XML preprocessing.

For example, whereas some designs might allow us to tell whether the 
document was encoded in utf-8 or iso-8859-1, others (including the one 
in the spec) don't. Being able to tell this, was not in the 
requirements, and I have not seen evidence that this is a strong enough 
requirement to justify revisiting our requirements (and hence the design).
Without this information, your goal cannot be met in general.

Jeremy (speaking personally)


Booth, David (HP Software - Boston) wrote:
> 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.
> 

-- 
Hewlett-Packard Limited
registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Wednesday, 13 June 2007 09:41:59 UTC