[
Lists Home |
Date Index |
Thread Index
]
Jeni Tennison wrote:
> Sure, but there's a lot of stuff being put into XPath 2.0 precisely so
> that XSLT processors *can* do this schema-dependent optimisation. I'm
> trying to get at whether that stuff is worthwhile or not.
Well, the obvious schema-dependent optimisations are
- take shortcuts while traversing the input tree for
doing selects and building key tables
- take advantage of known cardinalities of selected
node sets
- avoid exception handling in expressions, for example
like handling NaNs in "1+$whatever", and perhaps taking
shortcuts in evaluating expressions
The last point can also almost be done without schema
information, the only major difference being that the
input values for the expression have to be checked before
the expression is evaluated rather than during input
validation.
Whether any of the other two optimisations above will
pay off depends very much on the schema. If you have a
large input document and a very non-uniforn schema
(unlike the usual DB query results or XHTML), it may be
worthwile, in particular if you are sloppy and/or heavily
utilise the descendant, previous and following axes.
However, I can see a schema aware XSLT as a development
aid, the same sense as a type system for other progarmming
languages. Wouldn't it be nice to get warnings that
select="record/filed" is always empty (because of the typo)
and that 1+customername might be non-numeric? I belive
it could catch a lot of small problems in early development
stage which otherwise could even evade quite serious testing.
> and even then, it's utility hasn't yet been proven empirically.
Well, nobody really tried yet, so who knows? I belive
the ability to catch certain problems at style sheet compile
time, or at least at the first run, can easily save thousands
of man-hours of work. I just had an example where writing
select="output" instead of select="outputs/output" had cost
me two full days :-\.
J.Pietschmann
|
