Re: namespace node implementation

Repsonding to two of Michael's messages:

Kay, Michael wrote:

>  > Also note that existing XSLT implementations must implement the
>  > XSLT/XPath 1.0 semantics of namespaced nodes.  This is very
>  > expensive.
> It's probably not as expensive as you imagine, unless you imagine that 
> because something is described as a "node" in the formal data model, it 
> has to be represented by an "object" in the implementation.

In fact in Qexo a node is an (Object, int)-pair, where the Object is a 
top-level document or fragment, and the int is a magic cookie (loosely 
an index into a data structure).  I was inspired by Xerces' "document 
array mode".

Still, each element has its own set of namespace nodes, each of which 
have different node identity, and which all follow the element in 
document order.  "Allocating" a node can done cheaply: just incrementing 
a counter gives you a new magic cookie.  The trick is how to mange the 
cookies, how to implement document order efficiently, and how to extract 
the various namespace properties from the cookie.  Maybe later I'll work 
on how to do this.

 > There are sufficiently many open source XSLT processors that I think
 > you can be reasonably confident that any sensible ideas you come up
 > with have already been tried in one or more of them, and that they are
 > therefore covered by prior art.

It's a question of time:  I have enough problems understanding my own 
code (there is a lot of non-trivial code in Kawa, going back to 1996), 
so it is limited how much time I can spend trying to understand someone 
else's code!

But for example the Kawa pretty-printer implementation is a straight 
translation of the Common Lisp pretty-printer, just using more efficient 
data structures (Java arrays instead of lists for examples).  I did the 
translation with just a vague understanding of how it works ...
(I haven't managed to get it to work for XML output yet, alas.)
	--Per Bothner

Received on Wednesday, 22 October 2003 12:53:41 UTC