Cart
[Home] [By Thread] [By Date] [Recent Entries]
> I think I wasn't clear enough. The fact that the program is half > preparsed and encoded in XML, and half unparsed and contained > in strings, makes impossible certain queries over XSLTs (unless > parsing the attribute values). See the example I just gave to Michael > Kay. I don't think the case for representing the language in XML relies on introspection use cases. For that I agree you need something more like XQueryX. When people do transformations on stylesheets, it's usually at a fairly macroscopic level, e.g. looking at the structure of includes/imports, or replacing global variables or templates. Encoding the outer levels of the syntax tree in XML and the inner levels in micro-syntax seems to give a good balance between programmatic access and human readability, but like all compromises, it's not necessarily perfect for any single perspective. One of the most common examples of transforming a stylesheet is to change a sort key in response to a user request. The level of XML tagging makes that reasonably easy. In XQuery, I think one would have to do that by writing the query as a collection of text fragments in a Java or Perl application and constructing the customised query using string concatenation - which we're all familiar with from SQL, but which is decidedly messy: it certainly makes maintenance a nightmare. Michael Kay http://www.saxonica.com/
|
