[
Lists Home |
Date Index |
Thread Index
]
At 09:58 PM 5/10/2002 -0400, Elliotte Rusty Harold wrote:
>At 1:10 PM -0700 5/10/02, Jonathan Robie wrote:
>
>
>>And when there are so many different kinds of users, and many different
>>kinds of designers, each with their own perspective. That's almost always
>>the case in this kind of design work. The tools we are designing are
>>extremely general.
>
>Maybe they need to be less so. XSLT 1.0/XPath 1.0 was designed for
>document transformations and browser display. It was not designed as a
>general purpose XML query language. Now that new and very different use
>cases and requirements are getting piled on top of it, it's beginning to
>look not nearly as pretty.
It is not at all clear to me that the XML Query use cases should be
regarded as use cases for XSLT+XPath 2.0. I think that XQuery and XSLT may
well have different user communities.
I think I have a pretty good idea what some of the user communities are for
XSLT 1.0, and what some of the user communities for XQuery will be. I have
much less understanding of who the user community for XSLT 2.0 will be.
Will it be the same community that is now using XSLT 1.0? Will people
typically use XQuery for their queries and XSLT for their reports?
>I think maybe we need less general tools, not more. I think perhaps it's
>time to consider whether merging XQuery and XPath and XSLT actually makes
>sense. This may have been a mistake. The needs of the communities involved
>may be just too different for them to comfortably use the same tools.
I don't think that merging XQuery and XSLT is useful, and we are not doing
that, at least not at present. Both XQuery and XSLT needed a path
expression language, and I do think that it makes sense for them to use the
same path expression language.
>Unfortunately, the W3C culture makes it very difficult (close to
>impossible really) to admit that occasionally specs go off the rails, and
>need to be scrapped so that work can begin from scratch using the lessons
>learned from the failed project. I'm not 100% convinced XSLT/XPath is in
>that position now. I'm maybe 50% convinced. But I do think we need to
>honestly ask the question, and be open to the possibility of tossing a
>year's worth of work if that work proves to be fundamentally flawed.
Certainly we need to be open to asking the question.
In this case, I also don't think we would need to toss a year's worth of
work if we decided to scale back on XPath 2.0. That functionality would
still be found in XQuery. I do think that the use cases for this
functionality in XQuery are fairly strong. I'm still listening to the
discussion about whether we need it in XPath.
Jonathan
|
