W3C home > Mailing lists > Public > www-ql@w3.org > October to December 2003

Re: namespace node implementation

From: Per Bothner <per@bothner.com>
Date: Tue, 21 Oct 2003 17:52:47 -0700
Message-ID: <3F95D4DF.3050502@bothner.com>
To: james anderson <james.anderson@setf.de>
Cc: www-ql@w3.org

james anderson wrote:

> On Wednesday, Oct 22, 2003, at 01:18 Europe/Berlin, Per Bothner wrote:
>> Yes, but how are your "first class names" different from QNames, which 
>> can be passed, bound, and returned in XQuery?
> 
> the xml query drafts read as if qnames are "qualified names", that is a 
> (prefix localpart) pair, for which the so called "expanded qname", that 
> is the universal name, which is required for any given operation, is 
> determined at the point of the operation based on some set of 
> prefix-namespace bindings.

Unfortunately "QName" is used both in the lexical senses (a qualified 
name) and the semantic (data model) sense (an expanded qname).
A QName *value* is the latter.  QNames in the latter sense are 
"first-class names", while the former is just syntax that gets mapped 
(mostly at compile-time) to the latter.

 From the XML Schema specification Part 2 Datatypes section 3.2.18:

QName represents XML qualified names. The ·value space· of QName is the 
set of tuples {namespace name, local part}, where namespace name is an 
anyURI and local part is an NCName. The ·lexical space· of QName is the 
set of strings that ·match· the QName production of [Namespaces in XML].

>> Your implementation is of course a very natural one when using Common 
>> Lisp. 
> the implementation language is not material.

I could written it better as: "Your implementation is similar to the 
natural DOM-based one."

> the examples were chosen to use a data model which is a direct 
> reflection of the query data model. other data models are possible. the 
> storage efficiency of the particular model illustrated is not material 
> to the issue of namespace bindings.

You're right.  I'm pointing out at that storage (and run-time) 
efficiency are concerns that motivated my algorithm.  This is a 
discussion about implementation issues.

>>   That means that if $b and hence $c/b has a sub-element that uses the 
>> ns1 prefix, you can't find it by looking up the parent chain to get to 
>> $a.
>>
> a "first-class" name does not "use the ns1 prefix". that is what example 
> e/f/g was about. it is not necessary to carry the bindings within which 
> one would resolve the prefix if one folds constant names.

First-class names don't "use the ns1 prefix", but you need to be able to 
get namespace prefixes from element nodes so you can print the latter.

>>   let $a := <a xmlns:ns1="NS1"><b><ns1:bx/><ns1:by/></b></a>
>>   return $a/b
>>
>> This can print as either:
>>   <b xmlns:ns1="NS1"><ns1:bx/><ns1:by/></b>
>> or:
>>   <b><ns1:bx xmlns:ns1="NS1"/><ns1:by xmlns:ns1="NS1"/></b>
>> Both are valid, but I would much prefer the former.  My algorithm does 
>> that.
> 
>>  I think it would be difficult for your algorithm to do that without 
>> an extra pass.
>>
> why does it matter?

I'm not sure it "matters", but it does clutter up the output.  When you 
read the output back in again, you now have two namespace attributes 
instead of one.   You end up with namespace attributes migrating down 
towards the leaves, and hence duplicated, instead of nearer the trunk, 
where people prefer to read and write them (and where they were in the 
original document or program).
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/
Received on Tuesday, 21 October 2003 20:52:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:16 UTC