W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2003

RE: TR/xquery-operators/#func-doc

From: Michael Rys <mrys@microsoft.com>
Date: Tue, 20 May 2003 12:39:01 -0700
Message-ID: <5C39F806F9939046B4B1AFE652500A3A05598A06@RED-MSG-10.redmond.corp.microsoft.com>
To: <David.Pawson@rnib.org.uk>, <public-qt-comments@w3.org>

> M Rys wrote:
> >
> > You have to understand that XQuery has no problem with the 99% use
> > fn:document that takes a URI and returns a document.
> I dislike the mandate Michael.
> I keep repeating; xquery can do as it likes.
> I do however, care about xslt+xpath and the negative impact that
> is having on it.

[Michael Rys] Well, I see people that want to have as little difference
among the shared functionality as possible. And in this case, a way to
deprecate an XSLT functionality that they considered too complex.

Note that fn:doc() was not forced on the XPath/XSLT community by XQuery.
It was decided in the XPath gremium (jointly-owned by XSLT and XQuery)
that it is a good function to have in XPATH (not XQuery).

> > However,
> > fn:document has so many special cases that are almost never used
> ?by whom?
>   On what evidence do you make that assumption?

[Michael Rys] On the evidence of several thousand users of different
XSLT engines.
> > but
> > complicate the functionality, that we felt fn:doc() is
> > providing the 99%
> > functionality without all the additional baggage.
> >
> > You could see this to be the first stage of a deprecation of
> > fn:document() in XPath. First, we provide a simpler function.
> > In a later
> > version, fn:document() may be removed.
> And screw all the xslt+xpath users of document()?
> That's real good standards developments. I hope you feel proud.
> That's a quote worth keeping for AC forum.

[Michael Rys] Can you please stop these ad hominem attacks? If not, I
will stop answering your posts, since I do not feel I can have a dialog
with somebody that only insults and demands, but seems to be unable to

Every product and standard will want to deprecate functionality over
time that has proven to be too complex for the user value it delivers. I
think the approach of adding a simpler version early and recommend the
simpler version and SLOWLY, OVER TIME start to deprecate the old
functionality is a good approach. You seem to disagree, so I ask you,
how many standards did you develop that went beyond their v1? How many

> >
> > At least that's how I personally see the reason for keeping both in
> > XPath.
> I'm glad that's a personal view and not that of the WG.
> regards DaveP
> *** snip here ***
> -
> NOTICE: The information contained in this email and any attachments is
> confidential and may be legally privileged. If you are not the
> intended recipient you are hereby notified that you must not use,
> disclose, distribute, copy, print or rely on this email's content. If
> you are not the intended recipient, please notify the sender
> immediately and then delete the email and any attachments from your
> system.
> RNIB has made strenuous efforts to ensure that emails and any
> attachments generated by its staff are free from viruses. However, it
> cannot accept any responsibility for any viruses which are
> transmitted. We therefore recommend you scan all attachments.
> Please note that the statements and views expressed in this email
> and any attachments are those of the author and do not necessarily
> represent those of RNIB.
> RNIB Registered Charity Number: 226227
> Website: http://www.rnib.org.uk
Received on Wednesday, 21 May 2003 06:19:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:12 UTC