- From: David Carlisle <davidc@nag.co.uk>
- Date: Tue, 27 Jan 2004 13:09:48 GMT
- To: pcotton@microsoft.com
- Cc: public-qt-comments@w3.org
I replied to this message already, but I think I was rather tired and not particularly constructive, so this is a second reply, You may ignore the first, sorry about that. > We would be grateful if you could confirm that this response resolves > the questions you raised in your comment. I thank the WG for reconsidering the issue, but I do not find that the result, confirming the status quo, to be an acceptable outcome. [I should probably point out at this point that I do not represent a W3C member] > One of the major problems with these axes is that > they are very hard to use with static typing because their type > inference rules lose all type information. Removing the syntax does not remove the need for the functionality, it just forces the user to write the expression long hand. If it is acceptable that the static type inference can not infer a useful type to the resulting for expression then it should be aceptable that it deduces the same type for the equivalent axis expression. > In addition some WG members said there were implementation difficulties > with these axes Since expressions using these axes may be syntactically re-written to expressions that do not use them, it is hard to see any implementation issues. These re-writes could be part of the normalisation to the core syntax specified in FS. Having a machine do them is better for all concerned than the status quo, which is forcing the query author to do them. > and that the use of these axes impacted their ability to > create optimized implementations As commented above with repect to typing, removing the syntax does not remove the need for the functionality, so if users can not use the axis syntax, they have to use an equivalent expression. If it is acceptable for the "expanded" expression to be executed unoptimised, it must be acceptable for the axis syntax to be similarly unoptimised, conversely if the equivalent expression is being optimised by the system, the system could clearly optimise the axis expression. For the record, I believe these are the rewrites needed (more efficient ones may well be possible, I just wanted to show that this is a purely syntactic rewriting, in each case "foo" may be any node test. Certainly an "internal" rewrite could avoid the explict reversing that is done to make numeric predicates work. If however the axis is not available, an Xpath to Xquery translator is probably going to have to do these rewrites as written, which imposes a real cost. As these are not rigorously tested, I am prepared to believe that there are some bugs as written, but I am convinced that some such rewrites are possible and that it would be much better for the axis syntax to be allowed always, and for the system to automatically implement the best rewrite for that implementation than the status quo which forces the query author to try to second guess what is the best form of expression to use. For example an alternative apporoach to specifying the ancestor axis would have been to write a recursive function to walk up the parent axis. It would be much easier for the author of the system to know which is preferable for that system than the author of a query. preceding-sibling::foo let $here := . return ../foo[$here << .] preceding-sibling::foo[1] fn:reverse(fn:reverse(let $here := . return ../foo[$here << .])[1]) preceding::foo let $here := . return //foo[$here << .] preceding::foo[1] fn:reverse(fn:reverse(let $here := . return //foo[$here << .])[1]) ancestor::foo let $here := . return //foo[fn:not(fn:empty(.//node() intersect $here))] ancestor::foo[1] fn:reverse(fn:reverse(let $here := . return //foo[fn:not(fn:empty(.//node() intersect $here))])[1]) David ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
Received on Tuesday, 27 January 2004 18:04:21 UTC