Subject: Re: Named node lists From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Thu, 22 Jul 1999 22:57:59 -0500 |
Quoting Matthias Clasen <clasen@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>: > No need to do this. The standard contains the following (found in > the introduction to clause 10): > > The named-node-list data type is a subtype of the node-list data type > that represents a node-list each of whose members has a string-valued > property that uniquely identifies the node in the node-list. > > This implies that all operations on node-lists are applicable to > named-node-lists as well. > Ah... I kind of had a feeling this might be the case, and had intended to pose that question in my message, but forgot. I also read right through this material in the standard, but must not have picked up on it as you did. So, in theory, I could use (node-list-reduce) on a named node list, and there would be a property of each node that would have the name. --- The material above was written last night, then postponed until I could actually play with this. Well, suffice to say, I attempted to rewrite James' (copy-attributes) function using (node-list-reduce) on the named node list which is the value of an element's "attributes" property. James uses this property (accessible via the (attributes) function), along with (named-node-list-names), in his version to get a list of the names of all of the declared attributes of a function, which he then iterates through, using (attribute-string) to fetch the actual values. I figured, as long as you already have the node list of all the attribute assignments, why not grab the values through that? The answer is that the structure underneath each attribute assignment node is potentially so complex, that it isn't worth recreating the functionality of (attribute-string). So, I am left with a rewrite of James' function that does everything *except* actually get the value. An interesting exercise, but now abandoned. On the other hand, I *did* notice that James' version is not tail-recursive. I rewrote it to fix this, but a side-effect of this is that, to keep the attributes in the correct order, I had to use a (reverse) on the new list before returning it. What the performance impact of fixing the tail-recursion issue versus the extra (reverse) call is, I haven't tested. The version presented here (with a full example), however, also implements an optional attribute name mapping feature, providing a solution to Jany's recent problem. So, for those of you interested in this little oddity, the example files (DTD, instance, and style sheet) are available at: http://www.infomansol.com/test.zip http://www.infomansol.com/test.tgz Invoke Jade something like: jade -d test.dsl -t sgml test.sgml This will produce an identity mapping of the instance in test.sgml on standard output. To test the mapping feature, edit test.dsl, uncommenting the (default) rule near the bottom, and commenting the existing (default) rule below it, then run jade again. Note that I'm assuming you have your basic Jade environment set up correctly. Playing with SGML_CATALOG_FILES and such is left as an exercise that the reader should have done already. :) -Brandon :) DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Named node lists, Matthias Clasen | Thread | RE: why it is called a grove, Mason, James David ( |
"Temporary" DSSSList archive update, DSSSList Owner | Date | My memory is overgrown with groves., Brandon Ibach |
Month |