- From: <bugzilla@jessica.w3.org>
- Date: Mon, 17 Jan 2011 17:24:46 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11682 --- Comment #11 from Daniela Florescu <dflorescu@mac.com> 2011-01-17 17:24:46 UTC --- Liam, before we go ahead and so enthusiastically add those functions, could you please look at which programming languages have such functions IN THE CORE of the language and not in an additional library ? That's what my complaint is. We do not need those functions in the core of the language. That's why we have extensibility points, and modules for. That's what nicely designed programming languages like Java do. Best Dana (In reply to comment #9) > (In reply to comment #2) > > I think those functions should be eliminated from the standard for the > > following reasons: > > - they are not part of any user requirements > > Clearly not the case. Dear John, the W3C has a very specific was to describe requirements. It is called the Requirement document. Here is the link to it: http://www.w3.org/TR/xquery-30-requirements/ I do not see anything related to this functionality there. Why do we spend time approving requirement documents when later on we are allowed to bypass them any time we feel like !? > > > - the are 100% implementation dependent (no standard semantics of any kind) > > Also untrue. There are systems (like the cloud) where they make less sense than > others, but that is not a reason to suggest that the many other XQuery > implementations where they do make sense should lose this facility. Excuse me, by the text we will come up with (if we accept those) will be required to say: the semantics of such functions is implementation dependent. Otherwise, I will oppose it very strongly. Such functions make no sense in many environments-- cloud is only one of them, but what about data integration, distributed queries, etc !? Please do not forget that data integration for example is still one of the major use cases for XQuery. How should a query processor return for such functions when the query is split into smaller queries executed in a variety of other systems !? It makes perfect NO sense. > > > - they are untestable > > Not a reason to remove functionality. Yes, it is. We clutter the specification with lot of stuff -- for example we need to extend the dynamic context -- and it does not improve portability. The cluttering of the specification is not to be ignored. XQuery is complicated enough. > > > - they make no technical sense on environments that use virtualized > > infrastructure (aka cloud) > > See above. > > > - if implemented, they create a security breach > > Can you please explain this further? It's not obvious what you're referring to > here. John, I am a little but surprised by that comment. As soon as MarkLogic implements and ships those functions, please let me know, and I'll try to come up with a nice demo for you. It seems that demos are better then a thousand words. Best regards Dana (In reply to comment #7) > | So what are environment variables ? Operating system-related variables ? > | Process-related ? Implementation -defined completely ? > > The section to which you link gives an explanation, and a reference to POSIX. > I think it's pretty clear. It refers to the operating system concept of > environment variables. > > | 2. The text implies that the result of such a function call depends of the > | current status of the external environment where the program is executed. As > a > | consequence such a function is nondeterministic, right ? > > It's deterministic - stable. But the same query run on two different days might > give two different answers, just as with functions to get the current date. > > | 3. The text also implies that the invocation of XQuery external functions > could > | have side effects on the external environment. Shouldn't this better be left > to > | XQuery scripting ? Such a note can only add confusion. > > No. Consider the external function "putenv" to set a system environment > variable. > > | 4. In general, I am not convinced that such a function should be standardized > | and imposed to all XQuery processors. > > When the Working Group discussed it (in at least 3 calls and an email thread) > enough people felt it was useful, and/or had customers wanting it, or in some > cases already using a comparable facility, that it was added. > > In C or C++ on any POSIX-complaint system you could use the getenv() function > to implement this feature. That includes everything from MS-DOS through Unix > and Linux and OS X to Windows, as well as mobile platforms. Java systems would > probably map this to system properties. -- Configure bugmail: http://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 Monday, 17 January 2011 17:24:48 UTC