Re: Grddl Squirrel 6 test cases - My take

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