[
Lists Home |
Date Index |
Thread Index
]
> 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/
|
