- From: <David.Pawson@rnib.org.uk>
- Date: Fri, 16 May 2003 15:20:26 +0100
- 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 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 Friday, 16 May 2003 10:21:27 UTC