W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2007

[Bug 4261] [FS] technical: 8.2.3.1.1 Name Tests correct?

From: <bugzilla@wiggum.w3.org>
Date: Tue, 01 May 2007 23:00:30 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1Hj1Kg-0006YK-CP@wiggum.w3.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:18 UTC