Re: Seeking clarification, editorial comments, proposing transformation services

Thanks, and hopefully DanC and others in the WG have a chance to respond. 
The WG is on hiatus (basically closed), so all opinions are just my 
perosnal ones, without the Chair's hat on.

  On Sun, 15 Jun 2008, Simon Reinhardt wrote:

>
> 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.

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

XHTML uses profileTransformation as XHTML does not allow anything but the 
XHTML namespace at the root node. Profile's fate in HTML 5 is looking grim, but 
XHTML this works - so just think of profiles as "namespaces" for XHTML 
root nodes. However, profile Transformations are given another name 
because they are  technically a different kind of thing than a namespace 
transformation. We could have used the same attribute name I guess, but 
I'm not sure if that would have made life much easier and it would have 
confused the distinction between profiles for XHTML and namespace docs 
for XML.

  One cannot serve a XHTML document  legally with a namespace other than the 
XHTML one, so there should be no using a namespaceTransformation and 
profileTransformation on a single XHTML document unless XHTML adds some 
namespaceTransformations to their namespace doc.

  If you wanted a document to serve both as a profile and a namespace, yes, 
you should add two distinct properties. While repetitive, it seems to be 
of little cost. We could add this point to the errata for future 
versions of GRDDL.



> 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!

> 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.

A RDG graph is given by RDF/XML, N3, or any other serialization of RDF. 
So we do not restrict the output of all GRDDL transforms to RDF/XML on 
purpose.


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.



> 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" ;
> 	...


Not speaking for the WG, I have had similar thoughts and thought this was 
also a good idea.

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?

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. 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.

> 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.


Good point.

> Regards,
> Simon Reinhardt
>
>

-- 
 				--harry

 	Harry Halpin
 	Informatics, University of Edinburgh
         http://www.ibiblio.org/hhalpin

Received on Sunday, 15 June 2008 18:17:03 UTC