Re: namespace node implementation

On Thursday, Oct 23, 2003, at 15:23 Europe/Berlin, Kay, Michael wrote:

> > if saxon is using the name representation described in the earlier
> > message, the apparent namespaces at the time when the parent
> > was parsed
> > cannot affect the correctness of the model produced by this
> > operation.
> > neither the bindings apparent when the expressions were parsed nor
> > those when the expressions were compiled.
>
> I'm sorry, I simply do not understand this sentence (or one-and-a-half  
> sentences).

ok. i'll try again.
>
> Firstly, I don't see why the way I represent names internally should  
> prevent me from producing the correct output.

i have not suggested that any given name representation would preclude  
correct output.

i have observed that particular models for names require auxiliary data  
structures in order to produce correct output in the presence of  
certain modeling operations, because care must be taken to ensure that  
the operations not only produce the "intended" result, but also to  
ensure that they even close over the model. whereby it is not  
intuitively obvious what those auxiliary data structures are and how  
they are to be used. i have suggested that alternative models for names  
render the auxiliary data structures superfluous.

it was noted, that saxon represents names with a tuple which comprises  
a prefix, a local part string, and a uri (string). this is sufficient  
to implement operations which produce correct results without auxiliary  
data structures to represent in-scope namespaces.

further more it does not matter whether the name is resolved from a  
qualified name to a (prefix x localpart x uri) tuple when the  
expression was parsed to produce an abstract syntax, or when the  
abstract syntax was compiled into a sequence of operations. if the  
names are interned when the expression was parsed, they use the  
prefix-namespace bindings which appeared in the document at a  
particular position in the text. these are the "lexically apparent  
bindings".[0] if the names are interned by the compiler, they use a  
description of what xml literature calls the "in-scope namespaces."  
because there is necessarily correspondence between the values which  
these sets take on i an xslt/xquery compiler's dynamic contexts and the  
bindings which appeared in the text, they can also be called the  
"lexically apparent bindings".

in any case, onec the names are interned, those bindings are no longer  
pertinent, so my question was why they matter to saxon's  
implementation. (that is, exclusive of deprecated name operations)

>
> Secondly, I don't understand the distinction you are making between  
> "when the expressions were parsed" and "when the expressions were  
> compiled".
>
> And I'm not sure I understand what you mean by "apparent namespaces".
>
the rest was clear?

> >
> > > Right, and that's the problem I'm concerned about (assuming we're
> > > talking about the same thing).  Given:
> > >
> > > let $a := <a xmlns:ns1="NS1"><b ns1:x="X"/></a>
> > > let $c := <c xmlsns:ns2="NS2">{$a/b}</c>
> > >
> > > what is the result of get-in-scope-namespaces($c/b)?  It could be:
> >
> > it does not matter what get-in-scope-naemspaces returns.
> >
> > ? (defparameter $a (root (parse-document "<a xmlns:ns1='NS1'><b
> > ns1:x='X'/></a>")))
> > $A
> > ? (defParameter $c (root (parse-document "<c
> > xmlns:ns2='NS2'></c>"))) $C ? (setf (children $c) (children
> > $a)) (#<ELEM-NODE ||::\b 2 #x1693E16>) ? (write-node $c
> > *trace-output*) <c xmlns:ns2='NS2'><b ns1:x='X'
> > xmlns:ns1='NS1' /></c> #<ELEM-NODE ||::\c 1 #x169979E> ?
> >
> > with the appropriate model for names, it is possible to produce a
> > correct result document without any "in-scope namespaces."
> >

[0]  
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html#%25_idx_620
      
http://www.ida.liu.se/imported/cltl/clm/ 
node43.html#SECTION00700000000000000000
      
http://lists.w3.org/Archives/Public/www-xml-infoset-comments/ 
1999AprJun/0008.html
     http://www.flownet.com/gat/specials.pdf

Received on Thursday, 23 October 2003 12:33:19 UTC