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

Re: namespace node implementation

From: james anderson <james.anderson@setf.de>
Date: Wed, 22 Oct 2003 03:46:55 +0200
To: www-ql@w3.org
Message-Id: <9DE6B4FE-0431-11D8-A8B0-000393BB8814@setf.de>


On Wednesday, Oct 22, 2003, at 02:52 Europe/Berlin, Per Bothner wrote:

>
> 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].

at issue is when that happens. much of the xquery documents is written 
as if that point needs to be pushed back into the processor, even 
though, from the cases given, names are in fact immutable and can be 
reported as constants by the parser. those cases where names are 
constructed have not yet demonstrated that they need be constructed on 
the basis of (prefix X prefix->namespace X localpart) combinations 
rather than direct (namespace X localpart) combinations.

>
>> 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.

it should be possible to separate implementation issues which concerns 
names from those which concern other aspects of the model.

>
> 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.

the e/f/g example did exactly that. it issustrate the effect of caching 
the last-used prefix for each name and using that as a hint  when 
serializing if no binding is lexically apparent. this hint has nothing 
to do with the name-as-universal-name. it pertains to encoding only.

>
>>>   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).

there is nothing preventing one from adding additional nodes to the 
model.

the difficulty with an approach which seeks to afford the 
prefix-namespace bindings indefinite extent, is that it is hard to 
understand how it should operate with situations like

? (defParameter $e
   (root (parse-document
          "<e >
            <f xmlns:ns1='NS1' ns1:att='x'><g ns1:att-g='1'/><h 
ns1:att-h='2'/></f>
            <h xmlns:ns1='NS2' ns1:att='x'><i ns1:att-i='3'/><j 
ns1:att-j='4'/></h>
            </e>")))
$E
? (rotatef (first (children (second (children $e))))
          (first (children (fourth (children $e)))))
NIL
? (push (first (attributes (second (children $e))))
       (attributes (fourth (children $e))))
(#<STRING-ATTR-NODE NS1::|att| #x15D6036> #<STRING-ATTR-NODE NS2::|att| 
#x15D6B76>)
? (write-node $e *trace-output*)
<e>
            <f xmlns:ns1='NS1' ns1:att='x'><i NS2:att-i='3' 
xmlns:NS2='NS2' /><h ns1:att-h='2' /></f>
            <h xmlns:ns1='NS2' NS1:att='x' ns1:att='x' 
xmlns:NS1='NS1'><g NS1:att-g='1' /><j ns1:att-j='4' /></h>
            </e>
#<ELEM-NODE ||::\e 1 #x15D5ACE>
?

...
Received on Tuesday, 21 October 2003 21:47:28 UTC

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