OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath/XSLT 2.0 concerns

[ Lists Home | Date Index | Thread Index ]

On Tue, 2002-10-01 at 16:23, Jeni Tennison wrote:
> Hi Eric,
> > I don't know how representative it is, but there is also at least
> > one person (me) who has started to read these specs, seen that he
> > didn't agree with the requirements and didn't consider that the
> > addded complexity over XPath 1.0 is not worth the pain IHO and just
> > can't comment because he has no comments except "I'll stay with
> > XPath 1.0 and exslt as much as I can"...
> Which of the requirements don't you agree with? Do you have
> requirements that aren't or can't be met using extensions to XPath 1.0
> (e.g. for conditional expressions in XPath)? 

Basically the requirement I don't agree with is that it needs to be a
basis for XQuery and become strongly typed. 

More generally, I think that the balance of features between XPath and
XSLT 1.0 was pretty good (with maybe a couple of minor exceptions which
could be discussed such as document() and format-number() that could
have been part of XPath IMO) and shouldn't be radically changed.  

> In other words, are you
> saying that you don't think that XPath 2.0 is a good idea full stop
> (period), or are you saying that *this* XPath 2.0 isn't a good idea?

I don't feel like a stone resisting any change and I must say not *this*
XPath 2.0 even though the XPath 2.0 I would like would be 100 times
closer to XPath 1.0 than to *this* XPath 2.0.

> If it's the latter, then I think you've got a really good comment
> right there: "I was hoping that XPath 2.0 would meet my requirement to
> A, B and C but the complexity of XPath 2.0 means that the pain's not
> worth the gain. XPath 2.0 could be made simpler in order to satisfy my
> requirements without causing me pain by X, Y and Z."

But my requirements A, B and C are so tiny that are completely masked by
the level of modifications which is envisioned.

> I guess voting with your feet is OK, but that's what I meant about
> drawing the analogy with XLink. 2 or 3 years down the line we might
> realise that actually we did need some of the stuff that XPath 2.0
> does, but we're not using it because it's not designed in the way we
> needed it to be.

I don't want to sound negative, but I don't remember any of the comments
I have ever done to a W3C WG having ever been taken into account in a
positive way.

> Another thing we could try is to have a switch that makes XSLT 2.0 use
> XPath 1.0. XSLT 2.0 has some really useful stuff (multiple output
> documents, grouping, result-tree-fragments out the window,
> user-defined functions) so it'd be a real shame if we couldn't use
> them just because we wanted to avoid XPath 2.0.

If you say so I trust you that XSLT 2.0 must be a good thing! I'd note
though that the features you're mentioning are already implemented
through exslt. Having them as standard XSLT features would be great but
only if the price to pay can be lowered! 

Another concern I have is that I am not sure that it would be quickly
implemented and deploied in the major web browsers. Of course I can't
tell since I am not part of W3C, but do you have any commitment from
Microsoft about this?


Rendez-vous a Paris (Forum XML).
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS