- From: Jason Hunter <jhunter@acm.org>
- Date: Sun, 18 Apr 2004 10:36:37 -0700
- To: Michael Rys <mrys@microsoft.com>
- Cc: Howard Katz <howardk@fatdog.com>, Michael Kay <mhk@mhk.me.uk>, www-ql@w3.org
Michael Rys wrote: > This would not be backwards-compatible and have some interesting This is the first time I've heard of backwards compatibility being a major concern in a pre-1.0 release! Yes, I understand you're talking about XSLT 2.0, but I don't see why XQuery 1.0 needs to be backwards compatible with XSLT 1.0 or why the limitations that may need to be placed on XSLT 2.0 need to apply to XQuery 1.0 across the board. The ability to set a context sequence (not just a node) is a benefit to XQuery programmers. It should be allowed. > side-effects. The easiest way is that you define your input document to > be always a document node which can contain more than one element node. > Then //foo would give you exactly what you would expect (if you start on > an element node, the result probably would not be what you expect if you > have a foo element on the top). I (or my vendor) should be able to define it as makes sense in my/their context. Sometimes (rarely) a single node suffices. More often a sequence is what you need. If you want to find all foo elements in all the documents available to your environment, it sure be quite nice if there was a standard way. It's such a common need that vendors are all going to provide it. It's just a question of whether they'll be able to do it within the spec or by deviating. It's an arbitrary limitation that goes against a common need. > Also, you can set the context node to any node you want, as long as it > makes overall sense. "You can have any node so long as it's one." -jh-
Received on Sunday, 18 April 2004 13:45:05 UTC