- From: <bugzilla@jessica.w3.org>
- Date: Wed, 30 May 2012 02:41:58 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17227 --- Comment #2 from Liam R E Quin <liam@w3.org> 2012-05-30 02:41:57 UTC --- 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. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 30 May 2012 02:42:00 UTC