RE: General comments/feelings about XPath/XSLT 2.0

> Forwarded with permission from Mike Brown.
> 
> I'm sure I'll eventually be able to offer a more informed and 
> less emotional reaction, but at this point, I don't think I 
> can articulate the details of my discomfort with XPath/XSLT 
> 2.0 well enough to make a good case against it....

It's useful to know that you feel uneasy, but it's very hard to do anything
concrete in response to vague uneasiness, as I'm sure you appreciate...
> 
> All I can really say with certainty is that until the 
> villagers gather outside with torches and pitchforks, at 
> least 2 of the principal developers of 4Suite/4XSLT are not 
> at all interested in supporting XSLT 2.0.

There are a dozen or more products that implement XSLT 1.0. I doubt that any
of the vendors has made a positive return on their investment. Therefore, I
think it would be very surprising if every XSLT 1.0 vendor decided to invest
money in implementing XSLT 2.0. The market will not sustain that many
implementations, and I don't think we should be concerned if a few vendors
drop out of the race.
> 
> At any rate, there's not much motivation to implement 2.0 
> when none of our customers nor any of the other companies 
> we've worked for really seem to need many, if any, features 
> that aren't in 1.0, aside from the elimination of 
> result tree fragments.

I find it hard to see how you come to this conclusion. We have a regular
stream of XSLT users reporting the same difficulties with the 1.0
specification: grouping, string manipulation, date handling, summing or
sorting over computed values. 

As far as I can see, the only facility in XSLT 2.0 where there is little
evidence of demand from the existing user base is support for XML Schema and
its type system. My own view is equivocal on this, but there are good
arguments that the facilities are justified by the fact that they will
attract new users and new applications for XSLT; and in any case, we are
making these a separate conformance module so implementors are not obliged
to provide them. The market will decide.
> 
> What can the WGs do to stop us from walking away? I don't 
> know, but shorter and better-organized specs would be a 
> start. They should consider separating the implementation 
> details from what a user needs to know.
> 
> I mean as an implementer, I can appreciate things like 
> spelling out what conditions create what type of errors, and 
> very detailed, accurate, verbose explanations with very 
> specific terminology to describe the minutia.
> 
> But take, for example, the section on format-number(). As a 
> user just trying to remember the format of the arguments so I 
> can format a number in my stylesheet, I pore over the 3000 
> words(!) in that section only to come away
> *still* scratching my head as to how the heck to use the 
> stupid function.

W3C specifications have never aimed at being a tutorial for users. The XSLT
1.0 specification of format-number() was a disaster: it didn't have enough
detail for either implementors or users to predict the effects of a given
call, without trying it out against a JDK 1.1 implementation to see what
happened. The new specification is not ideal - it describes an algorithm,
which is something we usually try hard to avoid - but at least it tells you
what the function does for any given input.
> 
> Another example, just a minor nit: explaining push vs pull 
> processing. That's all good for people to know, but it's a 
> design pattern, not something that needs to be wasting space 
> in the spec. "Why did I just read that" or "why is 
> that being explained here, in between that and this" should 
> not be questions I am tempted to ask.

We've had some difficulty getting the right level of introductory material,
and organizing it to make it accessible. I certainly wouldn't claim that
we've got it right yet. But there are two pressures: to explain things more
clearly, and to stick to the normative facts. It's not easy to find the
right balance.
> 
> Scroll down a little bit and the sheer volume of terminology 
> being introduced is overwhelming. How is someone supposed to 
> read this and "get" it? XPath 1.0 wasn't arranged all that 
> well, but at least it was concise and requires little more 
> beyond the spec itself than a few more examples and diagrams 
> before someone can understand it -- "Here's your data types, 
> here's your tree model, here's your syntax and semantics, 
> here's your function library."

Well, there were things in XPath 1.0 that people had immense difficulty
with, for example the notion of axis direction and "proximity order". I
actually think the main XPath 2.0 language book is a vast improvement, both
in terms of specifying the language accurately and precisely, and in terms
of readability. I do agree that we have a problem of duplication and
consistency across multiple specifications - this is largely a consequence
of our internal processes, where we have tried to subdivide the task among
different subgroups and editorial teams. I think we should perhaps review
whether some reorganisation of the documents is possible now that the
technical content has become reasonably stable. Any concrete suggestions
along these lines would be welcome.
> 
> These new specs are going to require *volumes* of 
> supplementary material written in the Common Tongue to get 
> even experienced XPath/XSLT 1.0 users up to speed with it. On 
> the other hand, I suppose it gives writers of articles and 
> books on these subjects something to do. SGML, anyone?
> 
You seem to be expressing two separate concerns

(a) that the language is too big, and
(b) that the document set is unwieldy

Concerning (a), I think we need concrete suggestions as to which features
you think are unnecessary.

Concerning (b), we will strive to improve... but it's not easy. Care to
help?

Michael Kay

Received on Thursday, 19 September 2002 13:02:13 UTC