[
Lists Home |
Date Index |
Thread Index
]
--- Michael Kay <michael.h.kay@ntlworld.com> wrote:
> There is another logic as well. Things that are needed both in XQuery
> and in XSLT should ideally be done the same way in both. That keeps the
> total set of specifications smaller: less to implement, less to test,
> less to learn.
A large XPath is only easier to implement if you're implementing the full suite
of specs. For someone implementing only XSLT, XPointer or XPath in the DOM, the
everything-but-the-kitchen-sink approach increases implementation complexity. I
expect relatively few implementations of XQuery, compared to those of XSLT and
DOM. I also expect that only a few platform vendors will implement the full
suite and benefit from the supposed economies of scale. The partition you
propose makes Microsoft's, IBM's and Sun's jobs easier while making individual
tool developers' more difficult. Not a good tradeoff in my view.
>Many users will be using both languages. The argument
> that XPath should be the "greatest common subset" of XQuery and XSLT
> isn't an overriding one (for example we have chosen to keep function
> definitions separate, despite the argument that users may have to write
> the same function twice), but it's a factor to take into account.
Currently, there are no XQuery users, because XQuery doesn't exist. I expect
that even going forward, XSLT and especially XPath-in-DOM users will outnumber
XQuery users. In both the XSLT and DOM cases, XPath code will be embedded in a
language that includes loops and conditionals. The argument for duplicating
them in XPath seems weak to me.
Jim
=====
Jim Ancona
jim@anconafamily.com jancona@xevo.com
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
|
