This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The new tests for external variables take on a somewhat surprising format. Rather than a catalog element giving the value (and optionally the type) they require running a preliminary query, capturing the result (including xpath type) and passing it in to the main query. The only portable output format from Xquery is an XML document (serialised or as an in-memory dom of some sort) and this up to now has been the only required output form used by the test suite. However to take a particular example, to pass extvardeclwithouttype-10.xq I first need to evaluate extvardeclwithouttypetobind-10.xq and get the value 1 (fine) but if I grab the result of that as an XML document (the only way I'm set up to grab it currently) I basically get a text node with the string "1" and so the main query fails to add 1+1. The reasons that I currently fail this test seem to be only distantly related to the ability or not to handle external variables. (If the catalog had simply specified that I need to set the variable x to the integer 1, I'd have no trouble). This requirement to capture the typed value of atomic values from a Query is a major change in the test suite. I'm not sure currently how feasible this would be for me to do (I may just decide to not take these tests) but I thought I'd raise the issue to see if any other designs were or could be considered. Hopefully as you approach CR you'll get other submitted results from more commercial vendors and whether or not I skip a bunch of tests will be less of an issue, but if I'm faced with re-writing large chunks of my test harness to accomodate this test group, other implementors may face the similar issues... David
Some discussion of this on the query-talk list. It seems that other implementers are happy enough with this as it is, and I have a scheme now that seems to work OK, so if you choose to close this or mark it as invalid or wontfix I won't object. (Although a little more documentation of the range of possibilities open for implementing this in a test harness would not be unwelcome, so I'll leave this open for now) David
Hey David: Thanks for this comment and the suggestions you present. I will think of extra verbiage to put in the guidelines to help implementors run the tests. I will consult the task force about the catalog dictating a more direct way for the variable binding. I will mark the bug as ssigned and then as wontfix. Thanks, Carmelo
No objection, I flagged the issue but a) it wasn't as hard as I though for me to cope, and b) other implementors said they had no objections, so I'm closing.