Raw

Stefano elaborates on the problems he sees with GRDDL (now Last Call Working Draft!), specifically in relation to using the mechanisms with languages other than XSLT. His main point is that without further instruction from the spec, it isn't possible to use other languages (like Javascript) for transformation definitions.

I can't disagree with most of the content of Stefano's post, as it stands non-XSLT transform processing is undefined. But while I believe this is important stuff (there are a lot of RDFizers that could potentially be used with GRDDL), I agree with DanC's response that what the spec currently says is reasonable. If you know one way of baking a cake you know how to bake a cake, it isn't necessary to know every way of baking a cake, or limit yourself to that one way when you might find other recipes later.

One minor technical point - GRDDL transformations may produce RDF in a format other than RDF/XML (it's not explicit in the spec, but there's a test case which outputs Turtle).

In comments on my post yesterday, Yves Raimond suggested and Chimezie expands on the idea that RESTful services could do the transformations. In a limited sense that's already possible, e.g. using the W3C XSLT service, but this does seem like a very good area to explore for language-neutrality.

I'm now thinking my direct strategy for solving non-XSLT cases yesterday was probably misguided. The most elegant aspect of GRDDL is the way a transformation doesn't have to be directly associated with a document, it can be done by pointing to a profile (which describes the association, or points to another profile...), or using an existing reference to an XML namespace document (which describes the association to the transform, or points to another profile...).

So rather than trying to come up with a set configuration for Javascript which would make it behave like XSLT, a more flexible solution would be to have a profile include instructions on how a transformation is applied. This seems like it could be a use case for Mark Baker's RDF Forms (it also seems a creepily close fit for my own antediluvian attempt at process/service description, RPP).

In another mail DanC elucidates the effect of the architectural problem with pseudo-standard publishing and scraping (e.g. microformats without profile URIs) - it reduces the choice of other HTML authors. They have to be aware of all the conventions otherwise their own material may be interpreted in ways they didn't intend.