Re: Seeking clarification, editorial comments, proposing transformation services

Harry Halpin wrote:
> Note for individual instance documents you just use grddl:transformation 
> properties. So we're only talking about profiles/namespaces.

Yep, not talking about source documents here but about the case where I want to use one and the same URI for both a namespace and a profile.
Though I still wonder why the spec so explicitly talks about profile documents as being XHTML documents when they could just as well be any kind of document. Maybe you want to serve an XML document under a profile URI which links to a stylesheet so the browser can transform it into XHTML. It would still be possible to have this document be transformed into RDF which contains the statement <> grddl:profileTransformation <...blah.xsl>.

>> While reading the spec I noticed several typos and such but since it's 
>> a Recommendation I didn't bother noting them down. Only saw 
>> http://www.w3.org/2001/sw/grddl-wg/grddl-errata later. :-) So, adding 
>> to that just a few things:
>> Some tables have "Normative Statement" and "Mechanical Rule 
>> (Informative)" headers, some don't.
> 
> Could you specify precisely? That should be added to errata, along with 
> anything else you note!

Some typos are already listed in the errata. I couldn't be bothered though to read through the whole document again to note down everything I noticed, unfortunately I only found out about errata after I read through it. :-)
So, yes, one thing is the table headers for the rule boxes which are sometimes there, sometimes not.

> As regard this rule:
> 
> "If an information resource IR is represented by a conforming RDF/XML 
> document[RDFX], then the RDF graph represented by that document is a 
> GRDDL result of IR.
> 
> Note that it's a "base case" for recursive transveral of namespace 
> documents I think - i.e. if you keep going up namespace documents 
> looking for a GRDDL transformation and you eventually get a RDF/XML 
> document, that document itself is a GRDDL result. THink about the case 
> of a RDF/XML document with a GRDDL tranfsormation attached to it used as 
> a namespace doc.

Yeah, that's why I think this rule doesn't help in the case I have a problem with. Maybe I should rephrase it:
The spec says that you have a GRDDL result G if the root node of a document has a transformation with a transformation property and applying that transformation property to the root node results in an RDF graph G. My point is that what you get from applying the transformation property to the root node is not an RDF graph but the root node of an XML document _representing_ an RDF graph (or you get a textual result representing the graph, as is the case when the transformation results in N3 or something similar).
Well, the spec defines transformation properties to cover the whole process, so I guess parsing the resulting RDF/XML document into an RDF graph would be part of that. http://www.w3.org/TR/grddl/#txforms also says so, but the normative statement in there only talks about the specific cases RDF/XML and XSLT, not about other formats like N3 representations or JavaScript transformations.

> However, I believe some members of the WG wanted GRDDL to be restricted 
> to "client-side" transformations. However, the spec is written in such a 
> way that I hope this use-case can fit within the spec. Do you think it can?

I think the spec is definitely open to such a kind of transformation.

> In particular, it does not seem like grddl:serviceMethod or 
> grddl:sourceDocuemntParameter are required. You could just have the URI 
> of a web service as a GRDDL tranformation, and hope the GRDDL client is 
> web-service aware.

In the case of the over-engineered WS-* stack, maybe, I haven't work with that yet. :-)
In the case of a RESTful web service you would definitely need some form of describing it in RDF. Of course you could just assume that every such service accepts whole input documents through POST but it'd be nice to have the flexibility to just pass in the URI of the source document with a certain parameter. The format of the output could be controlled via conneg.

> Since transforms or not bound to XSLT etc., one could 
> imagine GRDDL Web-service aware agents. If you can't find out any 
> violations of the spec and you have some code, I'd be interested, so 
> keep me in the loop.

In that case I'll post it here. :-)

Received on Sunday, 15 June 2008 19:54:42 UTC