RE: Grddl Squirrel 6 test cases

> 
> I haven't formalized your test cases to integrate them in the 
> test suite yet; I'm not sure what difference it makes whether 
> the namespace document is served as application/xml or 
> application/rdf+xml; does any spec imply the interpretation 
> should be different? (there is a difference for the fragment 
> identifier handling, but I'm not sure it's relevant in this 
> particular case).

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.  The other
question is if it is not served with an RDF mimetype should one apply
transforms in the namespace doc itself.

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

OK.  
 
> Another option is to say that a GRDDL implementation should 
> not attempt to incorporate non-Valid RDF statements at any 
> stage in the process (in which case the interpretation is in 
> fact different in the end).

We'd need to be clear about what "non-valid RDF statements" are.  Do you
mean invalid RDF syntax?

> 
> I haven't thought fully about case 7 yet; I guess we need to 
> define GRDDL transformations in terms of statements collected 
> in the process of dereferencing the various statements (i.e. 
> whether a transformation can only apply at a certain stage in 
> the processing, or if all the transformations collected 
> during the process should be applied).
> Interesting question to explore :)

Indeed.  I think it would be helpful to have the algorithm spelled out.

> 
> Also, at some point, RDF/XML could be integrated into a 
> non-RDF root element; is that still the case? If so, we 
> probably need test cases to deal with that possibility as well.

Hmm, I'm not clear about that.  Clearly one can include the RDF/XML in
some other root element, but I'm not sure if one is then allowed to
interpret it as RDF/XML - can the context modify the meaning?

Brian

Received on Thursday, 9 March 2006 16:41:43 UTC