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

Let's try to be clear what the situation is.

The doc() function will be available in all three languages, XPath 2.0, XSLT
2.0, and XQuery 1.0.

The document() function is retained for backwards compatibility, and is
available only in XSLT.

Of course it would have been nicer to avoid the situation where two similar
functions are available to XSLT users. But the alternatives were:

(a) imposing the historical baggage of the document() function on XQuery
users
(b) making XPath incompatible with XQuery

and both of these are, I think, clearly worse than the solution we have
chosen.

If there is lack of clarity in the documents, I suspect it is in the
description of the convoluted history of this decision, which will disappear
in the final specifications.

Michael Kay



> -----Original Message-----
> From: David.Pawson@rnib.org.uk [mailto:David.Pawson@rnib.org.uk] 
> Sent: 16 May 2003 15:20
> To: jim.melton@acm.org
> Cc: public-qt-comments@w3.org
> Subject: RE: TR/xquery-operators/#func-doc
> 
> 
> 
> 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 away.
> 
> 
> 
> > 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 
> 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 Monday, 19 May 2003 06:11:53 UTC