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

WD-query-datamodel-20020430: "qualified" names and, eg., issue-0061:

From: james anderson <james.anderson@setf.de>
Date: Thu, 2 May 2002 07:50:41 -0400 (EDT)
Message-ID: <3CD129CA.D5835569@setf.de>
To: public-qt-comments@w3.org

The WD-query-datamodel-20020430 draft continues to use the term
"qualified" name in a manner which confounds reason. The usage is
somewhat improved, as the text attempts to clarify the intent with forms
such as "expanded qualified name" or "the value space of xs:QName". It
is not material, that the sources for the xs:Qname term themselves
confound reason. While these attempts are well-meaning, it would be more
effective to simply use distinct names for the distinct meanings.
A more adequate hierarchy is

(defclass name ()
	((local-part :type string)))

(defclass qualified-name (name)
	((prefix :type string :initform "")))

(defclass universal-name (name)
	((namespace :type string)))

(defclass expanded-name (universal-name qualified-name)

The "expanded-name" form is equivalent to the "QName object that is a
triple, local-name, namespace-uri, and prefix," which issue-0061
describes and suggests as a means to support the XPath name function.

It remains, however, to be demonstrated that any function other than the
name function demands this abstract name form. Furthermore, it remains
to be demonstrated that the name function itself - even when more
accurately identified as "qualified-name" rather than "name" - needs
this tripartite name form. The provisos which govern use of the "name"
function demonstrate that its result is valid only in a given namespace
binding environment. This environment has customarily been understood to
be that of the respective element - that is, its set of in-scope
namespace nodes. Issue 61 calls that assumption into question. A similar
concern arises with respect to attribute and element content which is
intended to denote universal names (see ref to the xslt requiremnt
below). the ensuing problems suggest that a more adequate definition for
the "name" function would make the namespace scope argument explicit.
which definition renders the expanded-name form superfluous, as the
universal-name form is then adequate for a complete xpath/xquery model.

As demonstrated by requirements 1.5 and 1.7 of WD-xslt20req-20010214, it
would be beneficial to rephrase the abstract syntax in terms of
universal names.

As demonstrated by the qname handling in WD-xslt20-20011220.html, in
particular the presence of ERR018 and ERR019, the languages can be
defined - and xslt is defined, such that the interpretation of their
abstract syntax does not require that qualified name prefixes be retained.

Received on Sunday, 5 May 2002 15:27:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:42 UTC