Seeking clarification, editorial comments, proposing transformation services

Hi list,

Three things that I need to get off my chest after reading the GRDDL spec. Maybe they've already been discussed but after skimming the subjects and some mails on this list I didn't find anything.

Question about design decisions for GRDDL: the spec seems to restrict profile documents to XHTML documents (not in the rule under "5. GRDDL for HTML Profiles" but under "7. GRDDL-Aware Agents": "each transformation indicated by any XHTML profiles, as in the GRDDL for HTML Profiles section."). Wouldn't any XML document that can yield a grddl:profileTransformation do? Why are there two properties grddl:profileTransformation and grddl:namespaceTransformation anyway when they basically say the same thing? If I serve a document which acts both as a namespace document and as a profile document then I need to include both properties just because my document may be discovered through different paths.

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.
And in the "general rule for using GRDDL with well-formed XML" it says "TP applied to R gives an RDF Graph[RDFC04] G" - however most transformations don't give an RDF graph but a representation of it, mostly in RDF/XML. So are those not GRDDL results? Later there is the 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." but this doesn't really change anything because the IR itself is not represented by an RDF/XML document, it only has a representation which is being transformed into an RDF/XML document. Also this would restrict results to RDF/XML representations. What if a transformation returns an N3 document? That's still a document representing a graph and not a graph by itself so going by the spec it's not a GRDDL result.

Finally an idea for extending GRDDL: GRDDL-aware agents should transform documents using the transformations they can discover for them. However it doesn't say which kind of transformation a GRDDL-aware agent is expected to understand so an agent which doesn't even support XSLT would still be a GRDDL-aware agent? Since agents are very extensible in regard to transformations, it would be nice to be able to describe the kind of transformation being used by websites, like what language/technology it is, how to run it, how to pass the input to it, how to interpret results and so on. Also it would be nice to take the burden of securing against malicious transformations off the shoulders of the GRDDL-aware agent.
Therefore I thought about GRDDL transformation services. Basically, you have a URI of a web service where you send your source document to. How that service works, if it's RESTful and you pass the URI of the document you want to be transformed to it with a GET parameter, or if it's SOAPy and you send the contents of the document inside the envelope, is determined by service descriptions which can be discovered alongside the transformation properties:

<xyz> grddl:transformation <abc> .
<abc> a grddl:TransformationService ;
	grddl:serviceMethod http:GET ;
	grddl:sourceDocumentParameter "uri" ;
	...

Special care has to be taken when GRRDLing documents which are not publicly available (e.g. which require HTTP Auth). Such a document could just use a namespace and the GRDDL-aware agent might think it's a good idea to look up that namespace, discovers a transformation service there and thoughtlessly sends the document to it, even though the author of the document did not intend that.

Regards,
  Simon Reinhardt

Received on Sunday, 15 June 2008 17:36:56 UTC