Lists Home |
Date Index |
On Mon, 2002-05-06 at 16:44, Uche Ogbuji wrote:
> I did disavow direct abuse of the XQuery formal model in this thread.
> I have no such reservations about XPath 2.0. It is a bloated mess,
> mostly because of the typing baggage, and I predict that XPath 1.0 and
> XSLT 1.0 will long survive the arrival of their 2.0 descendants.
> I, for one, as an avid XPath 1.0 and XSLT 1.0 implementor, am not
> likely to want to have anything to do with a good portion of what's in
> the 2.0 specs. It's too bad that there is a lot of good stuff buried
> in the wreck.
And separately, On Mon, 2002-05-06 at 17:15, Michael Kay wrote:
> On that score, I think you will find that a great deal of effort has been
> expended, and will continue to be expended, on reducing the complexity.
> Unfortunately, finding the right simplifications is not always easy,
> especially in a large committee. People (me included) are always less likely
> to fight against the addition of a feature they consider unnecessary than
> against the removal of one they really like, so it's always hard to make the
> language smaller.
Perhaps there is a reasonable ground for advancement in XPath without
the train wreck of 2.0.
My basic problem with XPath is 2.1.3: "XPath is a strongly typed
language with a type system based on [XML Schema]."
Perhaps by discarding that mash, it would be possible to define a subset
of XPath 2.0 (and XSLT 2.0) which rescues "the good stuff" without
inflicting the "baggage" type system.
The committee could then continue to produce whatever complexity they
felt appropriate, while those of us who prefer our XML without the type
system could continue to get our work done and even advance a bit beyond
As a developer planning an XPath implementation (for MOE and Regular
Fragmentations), this sounds to me like a potentially useful way to get
the most out of an untyped XPath.
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!