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

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

From: <David.Pawson@rnib.org.uk>
Date: Fri, 16 May 2003 15:20:26 +0100
Message-ID: <9B66BBD37D5DD411B8CE00508B69700F049E17AE@pborolocal.rnib.org.uk>
To: jim.melton@acm.org
Cc: public-qt-comments@w3.org

Jim said:
> We (perhaps obviously) did not expect that readers would be 
> confused by the 
> current wording, saying that doc() replaced document() in the 
> *joint* XPath 
> 2.0 and XQuery 1.0 F&O spec,

Hence my (possibly pedantic) comment. The document title implies
it is valid for xquery and xpath.
That would imply its content is true for both.
 Mikes statement is that document() is *not* replaced by doc()
for xslt (and its implicit xpath). 

Since its a specification, I think clarity is desirable.

 while the doc() function that is 
> not going to 
> be available in XQuery will be published in the XSLT 2.0 
> spec, where it 
> will be available.

Is that a typo? I assumed document() will be in xslt 2,
and not available in query?
  {confusion already?}

> Are you requesting a different explanation of this choice?  

Your choices appear made.
The near duplication of function with one exception I find
confused, or with my apparently biassed view, another 
case where the merger of query and xslt was a bad decision.

> Or are you 
> requesting that all XSLT-specific functions be specified in 
> the joint F&O 
> spec with some sort of flag indicating that the function is 
> unavailable in 
> XQuery (and, presumably, all non-XSLT-available functions 
> used by XQuery 
> similarly specified in F&O with such a flag)?

Its a spec, not a language. 
  If the WG must duplicate. Please isolate functions to their home
spec and don't mention them in others.
E.g. document() in xslt 
doc() in xquery. 

  Or are you 
> simply objecting 
> to provision of a new function with semantics that XQuery 
> users want and 
> need?
I have never made any requests or objections to what is needed/
wanted or proposed for xquery. Do as you see fit.

  I don't think that you're suggesting that we choose 
> exactly one of 
> the two functions and jettison the other,
As they are documented currently? Yes I do.
If you wish to separate them into their respective specs then duplicate

> because there are  real users that  need each of them;
I would hope so.

> similarly, I think you'd be more unhappy 
> if we chose to 
> jettison your favorite function function!
that's a view.

> I apologize for not understanding your intent, so any help in 
> improving my 
> understanding will be appreciated.

If this isn't clear please let me know.

regards daveP


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 

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 Friday, 16 May 2003 10:21:27 UTC

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