- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 01 May 2007 23:00:30 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4261 ------- Comment #3 from jmdyck@ibiblio.org 2007-05-01 23:00 ------- (Personal response) Consider the third premise: fn:namespace-uri-from-QName(expandedQName1) = AnyURI If expandedQName1 were in no namespace, then the result of fn:namespace-uri-from-QName() would be the zero-length string. But the empty string is not in the value-space of AnyURI, so the premise would not be satisfied. Thus, this premise requires that expandedQName1 be in a namespace. This also implies (somewhat indirectly) that, if QName1 has a prefix, then that prefix must map to a namespace URI (and not the null namespace). While the latter restriction agrees with the namespaces Rec, it is achieved by over-constraint: it is incorrect to require that expandedQName1 be in a namespace. (And then the second premise makes it even worse by requiring that the namespace be in the statically known namespaces, but that's beside your point.) So we cannot retain either of these premises. You might wonder if it would be possible to replace them with premises that achieve the prefix/namespace restriction without over-constraint. Certainly it would be possible, but I don't think it would be appropriate. (If here, then why not every other place where an "element QName" type appears?) Instead, I think the appropriate way to enforce the prefix/namespace restriction would be to remove the possiblity of statEnv.namespace mapping a prefix to #NULL-NAMESPACE (in FS 3.1.1 and 3.1.1.1 / Semantics / rules 1 and 3). Theoretically, I believe we're "safe" because the FS doesn't actually provide a way to _achieve_ such a mapping (see Bug 1542, Comment #1 and #3), but that's a) not very obvious, and b) not very reassuring.
Received on Tuesday, 1 May 2007 23:00:32 UTC