Dimitre,
I sense a bit of frustration in your remarks; I hope that I'm not
contributing to your frustration. I am, however, trying to be
realistic. Please let me try a different way to express what I intend to say.
The document in question (Functions and Operators for XQuery 1.0 and XPath
2.0) has several characteristics that are relevant to this discussion
(beyond the contents of the document, that is):
* It is intended to be used, perhaps in whole and perhaps in part, by two
different languages: XQuery 1.0 and XPath 2.0.
* Its two client languages (XQuery 1.0 and XPath 2.0) have different goals,
requirements, and audiences.
* It is in its first incarnation and is not being characterized as final;
it has been made available publicly precisely to receive the kinds of
comments that have arisen on this mailing list.
* Its owners of the document (the W3C Working Groups responsible for it)
and the editors of the document have a wide range of experiences; some come
from pure database backgrounds, some from true document backgrounds, some
from academia, some from industry, etc.
* It, like every other document will never be perfect, just as no
specification will satisfy all possible users, and no product will ever be
bug-free. All anybody can do is try to resolve as many requirements as
feasible. Among the requirements that must be balanced are those for
broader and deeper functionality and those for simplicity and elegance.
I should also note that there are multiple possibilities for the
progression of the specifications found in the draft we're discussing. It
might be published as a distinct document that is referenced by other
documents. It might be merged into the XQuery document. It might be
merged into the XPath document. Parts of it might be merged into the
XQuery document, other parts merged into the XPath document, and still
other parts published standalone. The XPath and XQuery documents might be
merged with or without the Functions and Operators material. Etc., etc.,
etc. I am not attempting to predict realistic of possible futures in these
remarks (in particular, I have not heard anybody mention merging XPath and
XQuery!), just trying to illustrate the breadth of alternatives that might,
in theory, occur.
Therefore, no, we are not likely to remove "XPath" from the title of the
specification. We are much more likely to continue to find ways to balance
competing requirements such as those you have raised.
Thanks for your on-going interest,
Jim
At 10:41 PM 9/8/2001 -0700 Saturday, Dimitre Novatchev wrote:
> While I want your needs to be met, yours are not the only needs
> under consideration. There are people/companies with demonstrated,
> articulated needs for a query language more powerful than XPath and we are
> trying to address those requirements, too. Trust me, I will not
personally
> force you to use that new query language ;^) You are more than welcome to
> continue using XPath.
>
> With tongue firmly in cheek,
> Jim
Thank you once again. I will continue to use XPath. A logical conclusion
from your
statement above is that there is a minor typo that has to be corrected --
will you
remove "XPath" from the title of the specification?
========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144
Oracle Corporation Oracle Email: mailto:jim.melton@xxxxxxxxxx
1930 Viscounti Drive Standards email: mailto:jim.melton@xxxxxxx
Sandy, UT 84093-1063 Personal email: mailto:jim.melton@xxxxxxx
USA Fax : +1.801.942.3345
========================================================================
= Facts are facts. However, any opinions expressed are the opinions =
= only of myself and may or may not reflect the opinions of anybody =
= else with whom I may or may not have discussed the issues at hand. =
========================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list