This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think this test imposes unreasonable demands on an implementation and/or test driver. To quote the comments in the test: " <!--* In order to pass test case 11 you *either* need to set * an environment variable QTTEST to the * string value 42, *or* available-environment-variables * must return () indicating no variables available. Now, a perfectly reasonable implementation might have available-environment-variables() and environment-variable() return the values of operating system variables as exposed using Java's System.getenv(). But if that's the way it's implemented, then there is no way a Java test driver can set particular environment variables to particular values. It can be done in the shell externally to the test driver application, but that's very difficult to achieve if, for example tests are being run in Java servlets, perhaps in multiple processes. It's tempting to change our implementation of environment variables so they map to Java system properties instead of operating system variables. That would enable us to pass this test. But I don't think we should redesign our product in a way that helps us pass tests but does nothing for users.
Hi Liam, Pleas may I ask you deal with this bug issue. Thanks
I'm not sure in what way you would like me to address the report. The motivation for adding the environment-variable() function was largely to access user-settable environment variables, including e.g. HTTP headers when invoked using a CGI interface. Part of my goal was to make it easier (or even possible) to use XQuery in some relatively hostile environments. So it seems reasonable to test that you can set a variable to a particular value. I'd be OK with parameterising the name of the variable in some way, or changing it to lower case, if it helps. I'd welcome suggestions. But I think the principle behind the test case is valid - test whether a user can set a variable to a specific value and retrieve it. And the point of environment variables is that they provide a (very crude) mechanism to communicate at a process level. e.g. from bash or sh on Linux or Solaris or OS X (the Windows mechanism is actually cross-process but otherwise similar). An alternative might be to allow implementations to pass if QTTEST and QTTEST2 are not listed in the list of available variables. Another alternative might be for your implementation to search first for environment variables and then for system properties - there's no way to prevent an implementation from making variables available that are *not* listed in available-environment-variables(). And that might be more useful for users.
I think I might wriggle my way out of this one by doing the same as with other context dependencies: have an API in the product that supplies an environmentVariableResolver, with a default implementation that calls System.getenv(), and a different implementation used in the test driver that simply recognizes magic variables like QTTEST and returns 42. It means the test is testing my test driver rather than my product, but it's probably the simplest way to handle it.
I've found a solution which enables me to pass the tests; it's a bit messy but adequate, so I'm withdrawing the bug.