Re: Named node lists

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