[
Lists Home |
Date Index |
Thread 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.
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
|
