W3C home > Mailing lists > Public > public-grddl-comments@w3.org > April to June 2007

RE: Comments on GRDDL draft [OK?] (#issue-faithful-infoset, XProc)

From: Dan Connolly <connolly@w3.org>
Date: Mon, 30 Apr 2007 10:12:48 -0500
To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
Cc: public-grddl-comments@w3.org
Message-Id: <1177945968.13028.97.camel@dirk>

On Mon, 2007-04-30 at 03:28 -0400, Booth, David (HP Software - Boston)
> > > 3. Are GRDDL transformations deterministic or not?

A short answer to this question is: yes, they are; a
transformation is a function:

"... each GRDDL transformation specifies a transformation property, a
function from XPath document nodes to ... RDF graphs."
 -- http://www.w3.org/2004/01/rdxh/spec#txforms

some details seem to be a little out of kilter...

I elided a spurious mention of RDF/XML documents there...
the range of the function is RDF graph.

grddl:TransformationProperty is a subclass of owl:FunctionalProperty.

Oops; or rather... it's supposed to be... darn... looks like
that got left out of the details of the vocabulary section.

I should fix that to match the "Transformation Algorithms" section.

> So, given that the WG decided to punt on the question of
> nailing down the input XML infoset -- and that decision
> by itself sounds reasonable -- the responsibility for
> unambiguous results seems to fall on the transformation
> property author.  Although in general we may not know
> what information set the XML document author intended, I
> think it *is* reasonable to assume that the transformation
> property author knows what XML infoset he/she intended.
> So how exactly can the transformation property author
> assure unambiguous results?  The spec seems to give no
> advice:
> http://www.w3.org/2004/01/rdxh/spec#txforms
> [[
> Therefore, it is suggested that GRDDL transformations be
> written so that they perform all expected pre-processing,
> including processing of related DTDs, Schemas and
> namespaces.
> ]]
> How?  I see Dan's comment in the WG meeting about this:
> http://lists.w3.org/Archives/Public/public-grddl-wg/2006Dec/att-0072/GRD
> DL_Weekly_--_20_Dec_2006.html#item10
> [[
> Dan: if you want you transformation to do xinclude, then
> make your transformations do xinclude
> ]]
> In accordance with Dan's comment, is the WG suggesting
> that transformation property authors must re-implement the
> xinclude spec if they want their results to be unambiguous?
> If so, how many other things would a responsible
> transformation property author also have to routinely
> re-implement in order to ensure unambiguous results?
> Why not permit the desired XML infoset treatment to
> be easily specified explicitly?

There's another W3C WG working on exactly this problem,
so we note their solution might work well:

XProc: An XML Pipeline Language[XPROC], a language for describing
operations to be performed on XML documents, has recently been published
as a W3C Working Draft. It merits consideration for expressing more
complex or sophisticated transformations which require control over the
flow of processing through a variety of XML processing tools. Using
XProc, one could apply a sequence of operations such XInclude,
validation, and transformation to a document, aborting if the result of
an intermediate stage is not valid, for example.
 -- http://www.w3.org/2004/01/rdxh/spec#txforms

>   For example, for the
> simple, non-namespace case, instead of defining the
> grddl:transformation attribute, how about allowing the
> author to choose between three attributes:
>   - grddl:transformation, which might have standard
>   XML pipeline infoset semantics;

As I noted earlier, we tried to find such a standard
and came to the conclusion that the state of the
art offers no standard. Did we miss something?

>   - grddl:unprocessedTransformation, which might have
>   semantics of NO infoset preprocessing; and
>   - grddl:ambiguousTransformation, which might have the
>   ambiguous semantics of the current GRDDL draft.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Monday, 30 April 2007 15:12:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:28 UTC