Lists Home |
Date Index |
> > 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
> > XPath 1.0.
> I get the feeling we have been here before.
> XPath 1.0 / XSLT 1.0 are vastly complicated by having to deal with
> namespaces. The namespaces spec is short and looks simple but it was pushed
> through with little realisation of the complexities it would cause in
> processing XML. My first reaction was that namespaces were so awful no one
> would use them and they would wither away, but I was wrong. People did use
> namespaces, and XSLT 1.0 had to support them despite the horrible complexity
> they caused. On the whole, the community has now learned to cope with this.
> Now we are in the same position with XML Schema. This time it isn't short
> and it doesn't look simple, but again people are using schemas increasingly
> and we can't wish them away. I don't think it's acceptable, if people go to
> the trouble of defining the data types they are using in their documents,
> that XPath and XSLT should ignore this information and treat eveything as if
> it were text (or guess that it might be a number, as XPath 1.0 does).
> Anyway, we get messages every week on xsl-list from people asking how to
> manipulate dates. I would love to reduce the complexity of the solution, but
> I don't think we can deny that the requirement exists.
This sounds like a common sense opening for conformance levels.
Let me ask the obverse of your point: for people whose XML/XPath/XSLT tools do not, and don't ever expect to support XSDL, why would the XSL WG shove it down their throats?
I am OK with having some extended facility for XPath to address Schema data types. I would have preferred that to be a separate module, spec, etc. But making it a fundamental part of XPath conformance is precisely the buckle in the rails that causes the wreck.
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel