- From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
- Date: Thu, 7 Sep 2006 11:04:27 -0400 (EDT)
- To: public-grddl-wg@w3.org
This is in regards to the original email [1] which is a source for (at least) 2 outstanding issues in the current GRDDL specification > With regard to the second aspect of your tests (a > dataview:transformation on an RDF root element), I think the > GRDDL specification should explicitly say that hitting an > RDF/XML representation ends the dereferencing loop - it > doesn't at this stage. I recall the last time this was brought up (i.e., what happens if a transform identified is actually an RDF/XML graph) Dan suggested it is an 'undefined situation'. What does it mean for the transformation algorithm to be an RDF graph? The only thing that comes to mind is if the RDF graph at the transformation URL contains data-view:*transformation statements which seems like an uneccessary level of indirection and has the potential to introduce cycles that the GRDDL processor would have to account for. So, I'm inclined to agree with Dom's suggestion that a GRDDL Processor should do nothing with the RDF/XML graph. On 09 march 2006 16:41 +0000, McBride, Brian wrote: > The RDF syntax spec says > > [[ > If the RDF/XML is a standalone XML document (identified by presentation > as an application/rdf+xml RDF MIME type object, or by some other means) > then the grammar may start with production doc or production > nodeElement. > ]] > > The significance of this is that it opens the way for an RDF document to > have a dataview:transformation attribute on its root element. I'm not sure if the significance above is in reference to a situation where the RDF/XML is the *source* for the GRDDL process. If so, then my take on this is that the GRDDL Processor should interpet an RDF/XML with a dataview:transformation attribute as equivalent to any other GRDDL Source Document: it should attempt to transform it. However, since the current thinking is that a GRDDL Processor can choose which transformation algorithm to apply it allows the processor to fail gracefully (even w/out clear guidance). Otherwise, it's the same as above (an undefined situation and nothing should be done). As for Test case 6: Case 6: The namespace document is an RDF document served as mimetype application/xml+rdf, with a GRDDL transform attribute about itself in the content. Seems to suggest that (perhaps) data-view:transformation should be also be interpreted as a link to a transform (same as data-view:profileTransformation and data-view:namespaceTransformation) if expressed in any resulting RDF. This is not neccessarily obvious as currently stated. For this specific test case, however, it seems like yet another 'undefined situation'. What does it mean to refer to a GRDDL Transformation against a document that has already been parsed as RDF? The difference between this and the first case (where a Transformation URL resolves to an RDF graph) is that a namespace document *can* be an RDF document and GRDDL is clear on what to look for if it is. However, once again, giving the GRDDL Processor the option to pick which transformation it applies allows it to fail gracefully in undefined situations, but I do think better guidance is needed for a GRDDL Processor. My specific suggestion: To the end of 5. GRDDL Transformations "A GRDDL Implementation can decide which transformation algorithms it applies. This determination can possibly be based on a local policy (with security in mind) or to situations that are otherwise undefined - for example, a namespace document whose meaning includes data-view:transformation statements made about itself. However, implementations *should* do nothing in situations where the resulting transformation algorithm is itself an RDF graph." [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Mar/0011.html Chimezie Ogbuji Lead Systems Analyst Thoracic and Cardiovascular Surgery Cleveland Clinic Foundation 9500 Euclid Avenue/ W26 Cleveland, Ohio 44195 Office: (216)444-8593 ogbujic@ccf.org
Received on Thursday, 7 September 2006 15:05:05 UTC