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...).
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.@en