Erik Naggum wrote: > Where is that annoying conformance test guy who stresses the useless > corners and boundary conditions of the standard when you need him?
I haven't tested the reader (much) yet, so I don't feel comfortable offering an opinion on this at this time.
Paul (who is trying to recover from attempting to test section 19)
wallacethinmi...@eircom.net (Russell Wallace) writes: > A trivial little question, but one that's been bugging me: Is there a > name for that set of characters legal in Lisp identifiers?
A character.
I think you don't mean what you wrote.
A Lisp identifier is a symbol, not a piece of text. Some code is constructed entirely from programs and never even goes through the text phase and has no such thing.
All characters are, in principle, allowed in a symbol. You have to use \x or |xxx| escaping to get some in.
If your question is about symbols, rather than about identifiers, that's a legit thing to ask, but is a completely different matter. Not all symbols are identifiers, though.
> For most languages this would be "alphanumeric" (perhaps with a > footnote that _ is regarded as a letter in this context), but Lisp > includes characters like + and - that most languages regard as > punctuation.
Most languages are parsed from text to program, with no intermediate phase. In Lisp, text (if there was any) has been parsed prior to the time that expressions start to become considered as programs. Lisp programs are not made out of characters, they are made out of structured (i.e., already extant and composed) objects (conses, symbols, numbers, etc.).
> * Russell Wallace > | A trivial little question, but one that's been bugging me: Is there > | a name for that set of characters legal in Lisp identifiers? For > | most languages this would be "alphanumeric" (perhaps with a footnote > | that _ is regarded as a letter in this context), but Lisp includes > | characters like + and - that most languages regard as punctuation.
> The type STANDARD-CHAR covers the set of characters from which all > symbols in the standard packages are made. This simple fact may > give rise to the invalid assumption that there must be a particular > character set from which all symbols must be made.
Although, in contrast, if you're trying to write code to share around, it's a good conservative set. In the same sense as it's conservative to write your programs in English.
I experimented with a multi-user, multi-lingual system (not Lisp-based) for a while, and we eventually concluded that multilingualism is cool but is best left to the interface. At the programming level, the ability to have one name for one function, is important to being able to search for and update callers. Making multiple names (for each language) for a function both impedes search and makes programs look dumb. Making each package impose its own language choice makes it hard to read programs and sometimes raises argument order/naming issues. And so, in the end, if you retreat to some language to program in as a common language, English once again rears its ugly chauvinistic self as the obvious alternative. And with it, the standard characters are a nice safe set to build out of, since there's no real reason to invite portability problems when you're already within striking distance of easy portability.
The more power you get, the more the burden is on you to use it wisely. Just because you can do something doesn't mean you should...
> However, the functions INTERN and MAKE-SYMBOL take a STRING as the > name of the symbol to be created, and there is no restriction on > this /string/ to be of type BASE-STRING. Likewise, the value of > SYMBOL-NAME is only specified to be of type STRING, with no mention > of the common observation that it may be a SIMPLE-STRING regardless > of whether the corresponding argument to INTERN or MAKE-SYMBOL was.
Yeah, I think this last is left to implementations. I don't think there is any really good reason to require it to be a simple string. An implementation might want to experiment with non-simple strings in ways the designers didn't anticipate.
> I am particularly fond of using the non-breaking space in symbol > names, just as I use it in filenames under operating systems that > believe that ordinary spaces are separators regardless of how much > effort one puts into convincing its various programs otherwise. I > know people who think there ought to be laws against this practice, > but sadly, the Common Lisp standard does not come to their aid.
Erik, I have missed your singular ability to make me mad and make me smile at the same time. I wish I could decide whether I think this practice is clever and forward thinking or just an irritating loophole. But either way, the problem exists, and you're just highlighting it.
wallacethinmi...@eircom.net (Russell Wallace) writes: > my question wasn't about Lisp, but about English terminology. I gather from > Erik's explanation that the answer is "Lisp doesn't regard any such set as > special enough to merit a short name", though, so I'll just make up one > myself, something like "ordinary characters".
I think you're still making a conceptual error. You're all concerned about the name for this concept, but the problem (in Lisp) is that the concept itself doesn't exist.
There are CHARACTERs, which for example can be put together into STRINGs. SYMBOLs have names which are STRINGs, composed of any CHARACTER at all.
There is _no_ (sub)set of CHARACTERs in Lisp which does what you want. You're searching for the name of a concept, but the concept itself is not well-formed. No wonder it doesn't have a name.
(In particular: whether the CL reader interprets a token as a symbol is a result of a parsing algorithm, not a result of whether the constituent characters are in your magic subset or not. If the parser can't interpret the token as some other data type, then it becomes a symbol. You're imagining the wrong algorithm for choosing to make a token into a symbol.)
-- Don ___________________________________________________________________________ ____ Don Geddis http://don.geddis.org/ d...@geddis.org
> That won't work; (, ) and ' are "punctuation" (?) and normally > recognized by the reader as special characters. (I'm talking about the > normal case, not what you can persuade the reader, interner or > whatever to do if you try hard enough :))
Of course, surrounding the symbol name with vertical bars might be considered "trying hard enough" by some people.
-- Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote: > wallacethinmi...@eircom.net (Russell Wallace) writes:
>> (defun )(')( ...)
> (defun |)(;)| ( ...)
>>That won't work; (, ) and ' are "punctuation" (?) and normally >>recognized by the reader as special characters. (I'm talking about the >>normal case, not what you can persuade the reader, interner or >>whatever to do if you try hard enough :))
> Of course, surrounding the symbol name with vertical bars might be > considered "trying hard enough" by some people.
That's how I might have felt until I found myself with the requirement to parse some useful metadata out of an XML dtd. <yechh> Now it seems like the most natural thing in the world to code:
Speaking of which, this is related to a Lisp NYC project to create a toy exchange with a FIX (Financial Info Exchange) protocol interface. The original protocol was a flat "tag=value;"+ format. An XML version was developed and a DTD along with it, which I used just to get the metadata.
Now we want to leave the land of XML behind and write out a nice sexpr variant of the same metadata as /our/ spec (we do not have to worry about matching the real Fix tit for tat since this is a toy exchange not meant as a FIX client testbed).
Of course it is easy enough for me to come up with a sexpr format off the top of my head, but I seem to recall someone (Erik? Tim? Other?) saying they had done some work on a formal approach to an alternative to XML/HTML/whatever.
In article <4004f268.138951...@news.eircom.net>, wallacethinmi...@eircom.net (Russell Wallace) wrote:
> (defun )(')( ...)
> That won't work; (, ) and ' are "punctuation" (?) and normally > recognized by the reader as special characters. (I'm talking about the > normal case, not what you can persuade the reader, interner or > whatever to do if you try hard enough :)) So there's "whitespace", > "punctuation" and... what's the third category called? Not > "alphanumeric"... "constituent characters"?
Yes, that's the phrase used in the specification.
Note, however, that a token consisting only of constituent characters is *not* necessarily going to be parsed as a symbol. Both numbers and symbols are made up only of constituent characters (unless you make use of radix prefixes like #o and #b). Thus, 123e.456 is a symbol, 123.456 and 123e456 are floats, and 123e is a symbol or integer depending on the value of *READ-BASE*.
There are tables in the ANSI spec and CLTL that list all the standard character types and constituent character attributes. The character types are whitespace, terminating macro, non-terminating macro, single escape, multiple escape, and constituent (the text also mentions "illegal" characters, although no standard characters are of this type).
-- Barry Margolin, bar...@alum.mit.edu Arlington, MA
* Kenny Tilton | Of course it is easy enough for me to come up with a sexpr format off | the top of my head, but I seem to recall someone (Erik? Tim? Other?) | saying they had done some work on a formal approach to an alternative | to XML/HTML/whatever. | | True that? If so, I am all ears.
Really? You are? Maybe I didn't survive 2003 and this is some Hell where people have to do eternal penance, and now I get to do SGML all over again.
Much processing of SGML-like data appears to be stream-like and will therefore appear to be equivalent to an in-order traversal of a tree, which can therefore be represented with cons cells while the traverser maintains its own backward links elsewhere, but this is misleading.
The amount of work and memory required to maintain the proper backward links and to make the right decisions is found in real applications to balloon and to cause random hacks; the query languages reflect this complexity. Ease of access to the parent element is crucial to the decision-making process, so if one wants to use a simple list to keep track of this, the most natural thing is to create a list of the element type, the parent, and the contents, such that each element has the form (type parent . contents), but this has the annoying property that moving from a particular element to the next can only be done by remembering the position of the current element in a list, just as one cannot move to the next element in a list unless you keep the cons cell around. However, the whole point of this exercise is to be able to keep only one pointer around. So the contents of an element must have the form (type parent contents . tail) if it has element contents or simply a list of objects, or just the object if simple enough.
Example: <foo>123</foo> would thus be represented by (foo nil "123"), <foo>123</foo><bar>456</bar> by (foo nil "123" bar nil "456"), and <zot><foo>123</foo><bar>456</bar></zot> by #1=(zot nil (foo #1# "123" bar #1# "456")).
Navigation inside this kind of structure is easy: When the contents in CADDR is exhausted, the CDDDR is the next element, or if NIL, we have exhausted the contents of the parent and move up to the CADR and look for its next element, etc. All the important edges of the containers that make up the *ML document are easily detectible and the operations that are usually found at the edges are normally tied to the element type (or as modified by its parents), are easily computable. However, using a list for this is cumbersome, so I cooked up the «quad». The «quad» is devoid of any intrinsic meaning because it is intended to be a general data structure, so I looked for the best meaningless names for the slots/accessors, and decided on QAR, QBR, QCR, and QDR. The quad points to the element type (like the operator in a sexpr) in the QAR, the parent (or back) quad in the QBR, the contents of the element in the QCR, and the usual pointer to the next quad in the QDR.
Since the intent with this model is to «load» SGML/XML/SALT documents into memory, one important issue is how to represent long stretches of character content or binary content. The quad can easily be used to represent a (sequence of) entity fragments, with the source in QAR, the start position in QBR, and the end position in QCR, thereby using a minimum of memory for the contents. Since very large documents are intended to be loaded into memory, this property is central to the ability to search only selected elements for their contents -- most searching processors today parse the entire entity structure and do very little to maintain the parsed element structure.
Speaking of memory, one simple and efficient way to implement the quad on systems that lack the ability to add native types without overhead, is to use a two-dimensional array with a second dimension of 4 and let quad pointers be integers, which is friendly to garbage collection and is unambiguous when the quad is used in the way explained above.
Maybe I'll talk about SALT some other day.
-- Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote: > * Kenny Tilton > | Of course it is easy enough for me to come up with a sexpr format off > | the top of my head, but I seem to recall someone (Erik? Tim? Other?) > | saying they had done some work on a formal approach to an alternative > | to XML/HTML/whatever. > | > | True that? If so, I am all ears.
> Really? You are? Maybe I didn't survive 2003 and this is some Hell > where people have to do eternal penance, and now I get to do SGML all > over again.
First, thx, <<quad>>s are nice. I was thinking about compiling some XML-alternative syntax into internal Lisp structures (which is why I was wondering why I even need someone else's proposal, I can just write the internal structures out as READable forms).
I see <<quads>> are something that allow one to navigate the structure itself, and that this is useful if one does not want to gobble up the whole of the structure. I'll keep <<quad>>s in mind if I ever want a random-access markup store.
Heh. My absence from news shows. Over here in Europe, «» are the proper quotation marks, instead of the various versions of " that are not in ISO 8859-1. The « and » are not integral to the name of the type, it's just "quad".
| I was thinking about compiling some XML-alternative syntax into | internal Lisp structures (which is why I was wondering why I even need | someone else's proposal, I can just write the internal structures out | as READable forms).
You always have to consider how much information you want to retain from the parsing process. The sexpr contains just enough information for its uses, but the only navigation you ever do with sexprs is to go down the CAR or CDR.
| I see <<quads>> are something that allow one to navigate the structure | itself, and that this is useful if one does not want to gobble up the | whole of the structure.
Hm, I think it makes most sense when you do want to gobble up the whole of the structure. The point about storing pointers to entity fragments using quads, too, was that contents usually dwarfs the markup in volume. When end-tags make up 25% of the volume of the document, however, the start-tags make up another 25%, and when I designed the quad and its various implementations in Common Lisp and in special languages, the strong desire was to be able to load large documents into memory.
| I'll keep <<quad>>s in mind if I ever want a random-access markup | store.
That seems like you decided on their utility before trying them out, while I have really tried to build a system as useful for XML-like data as the cons cell is for Lisp-like data. Instead of inventing the array and regarding cons cells as random access into the list, we just use lists made up cons cells because that affords the navigation we need when processing them. Likewise, the quad affords the navigation we need when processing XML-like structures. When I suggest that an implementation that does not provide the ability to add native types use a two-dimensional array, it is not because it makes random access into the document possible but because it saves a lot of memory.
-- Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote: > * Kenny Tilton > | I was thinking about compiling some XML-alternative syntax into > | internal Lisp structures (which is why I was wondering why I even need > | someone else's proposal, I can just write the internal structures out > | as READable forms).
> You always have to consider how much information you want to retain > from the parsing process. The sexpr contains just enough information > for its uses, but the only navigation you ever do with sexprs is to go > down the CAR or CDR.
Maybe I should have said more about what I am doing. I wrote a poor man's XML parser just so I could read a DTD just so I could get metadata about the required structure of Financial Info Exchange (FIX) protocol messages. The funny thing is we do not plan to support FIXML, but the DTD for it looked like the best source of metadata about the original "tag=value" format.
What we want to do is now leave the world of XML behind and just write out the metadata in some nice Lisp-friendly way.
The DTD was nothing more than !ENTITYs, !ELEMENTs, and !ATTLISTs. Anyway, I just created hashtables for entities and elements which I converted to structs, and the element struct had a slot for attributes, etc etc etc.
Now I want to write it all out readably so we can leave XML behind. As it is, I had to fill in some gaps by adding to the DTD so the parse could produce the Right Thing (this being more fun than the alternative of hardcoded additions to the internal structures post-parse).
It's a little fuzzy, but one element would define a record and have a content string that listed all the field elements. So at run time I dynamically use bits of the same parser to read that string and determine the fields (I sensed that I had to leave it to the last second to support dynamic redefinition of elements, but perhaps this step could also be <<pre-compiled>>) and then look up the fields to determine their attributes in turn to assist with parsing of the field data.
> | I'll keep <<quad>>s in mind if I ever want a random-access markup > | store.
> That seems like you decided on their utility before trying them out,
Maybe I just misunderstood. If quads just give me a link to the parent, well, in the case of the DTD, all the entities, elements, and attributes had the same parent, the XML dtd document. So I imagined an awful lot of serial searching, repeated over and over again for the same message type, and yes, I made a gut determination that I could use the names of things as keys to a hash table and turn a record expansion into so many keyed lookups.
Well, maybe I am all wet. If performance is my concern, I need only memoize things like record expansions, something I should do anyway even with the keyed lookups. Memoization will internally involve its own hash tables, but at least they are hidden behind a functional interface, which would be nice.
> However, the whole point of this exercise is to be able > to keep only one pointer around. So the contents of an element must > have the form (type parent contents . tail) if it has element contents > or simply a list of objects, or just the object if simple enough.
> Example: <foo>123</foo> would thus be represented by (foo nil "123"), > <foo>123</foo><bar>456</bar> by (foo nil "123" bar nil "456"), and > <zot><foo>123</foo><bar>456</bar></zot> by #1=(zot nil (foo #1# "123" > bar #1# "456")).
Do we need each child to refer to its parent? Why not a format with the parent first and then one or more children understood to share the same parent?
Erik Naggum <e...@naggum.no> writes: > * Kenny Tilton > | First, thx, <<quad>>s are nice.
> Heh. My absence from news shows. Over here in Europe, «» are the > proper quotation marks, instead of the various versions of " that are > not in ISO 8859-1.
What do you mean? The proper quotation marks for Swedish is "ninety-nine ninety-nine", while in eg the UK "sixty-six ninety-nine" is used. "Gåsögon", the marks you used can also be used in Swedish but are then often used »like this». In Norway they are pointed outwards, like you did, but in Denmark they are »pointed inwards« instead[1].
Or did you just mean to say that since ISO 8859-1 is lacking the proper "-style quotation marks, it is better to use «»? Because I believe the quote marks to be used are dictated by the language the text is written in, so that English text should be written using English quotation marks, Swedish text using Swedish quotation marks, etc.
>> * Kenny Tilton >> | I was thinking about compiling some XML-alternative syntax into >> | internal Lisp structures (which is why I was wondering why I even need >> | someone else's proposal, I can just write the internal structures out >> | as READable forms).
>> You always have to consider how much information you want to retain >> from the parsing process. The sexpr contains just enough information >> for its uses, but the only navigation you ever do with sexprs is to go >> down the CAR or CDR.
> Maybe I should have said more about what I am doing. I wrote a poor > man's XML parser just so I could read a DTD just so I could get metadata > about the required structure of Financial Info Exchange (FIX) protocol > messages. The funny thing is we do not plan to support FIXML, but the > DTD for it looked like the best source of metadata about the original > "tag=value" format.
>>> * Kenny Tilton >>> | I was thinking about compiling some XML-alternative syntax into >>> | internal Lisp structures (which is why I was wondering why I even need >>> | someone else's proposal, I can just write the internal structures out >>> | as READable forms).
>>> You always have to consider how much information you want to retain >>> from the parsing process. The sexpr contains just enough information >>> for its uses, but the only navigation you ever do with sexprs is to go >>> down the CAR or CDR.
>> Maybe I should have said more about what I am doing. I wrote a poor >> man's XML parser just so I could read a DTD just so I could get >> metadata about the required structure of Financial Info Exchange (FIX) >> protocol messages. The funny thing is we do not plan to support FIXML, >> but the DTD for it looked like the best source of metadata about the >> original "tag=value" format.
> What's wrong with CL-XML?
I couldn't understand the installation instructions.
And the doc said it pulled things into CLOS instances, and then I would use XQuery/XPath/XCrap to get at the info. And I did not really want to do XML (in which case getting all fancy like that might make sense), I just wanted to suck some info out of a DTD.
In fact, someone on the team already said I screwed up, I should have parsed an HTML file for the same info, which would be more accurate in certain dark corners where the XML orientation of the DTD diminishes the correspondence to the non-XML syntax.
And this is Lisp, I wrote my crappy hard-coded parser in less time than it would have taken to figure out how to install cl-xml. And about 100 lines of code so no one on our team has to bother with cl-xml.
> On Tue, 20 Jan 2004 19:36:31 GMT, Kenny Tilton <ktil...@nyc.rr.com> wrote:
> > Marco Antoniotti wrote:
> >> What's wrong with CL-XML?
> > I couldn't understand the installation instructions.
> So I'm not the only one... :)
the mind boggles.
the distribution unpacks to a directory at the top level of which is a collection of files with names in the form
load{+,-}cl-http{+,-}instanceNames.lisp
and a file
load.lisp
which is a symbolic link to
load-cl-http+instanceNames.lisp
that is to say, if one is using one of the supported lisp implementations and one types
(load #p"<pathname to the load.lisp file")<return>
at the the repl prompt, one compiles and loads the parser in an environment without cl-http and in a mode which implements names as instances (as opposed to symbols).
which aspect of this prospective process does one find difficult to understand?
> But you know that there are some more "lightweight" solutions out > there? You could have said
> (asdf-install:install :pxmlutils)
> or
> (asdf-install:install :xmls)
> and - voilà! (At least I hope so...)
should there be any cause for uncertainty as to how to processed, the release includes a directory
Edi Weitz wrote: > On Tue, 20 Jan 2004 19:36:31 GMT, Kenny Tilton <ktil...@nyc.rr.com> wrote:
>>Marco Antoniotti wrote:
>>>What's wrong with CL-XML?
>>I couldn't understand the installation instructions.
> So I'm not the only one... :)
> But you know that there are some more "lightweight" solutions out > there?
Aw, c'mon, I can write a hard-coded parser in my sleep. Besides, now I can put XML on the resume. I'll just have to pretend i wrote it in a real language.
On Wed, 21 Jan 2004 00:20:48 +0100, james anderson <james.ander...@setf.de> wrote: > the mind boggles.
> the distribution unpacks to a directory at the top level of which is > a collection of files with names in the form
> load{+,-}cl-http{+,-}instanceNames.lisp
> and a file
> load.lisp
> which is a symbolic link to
> load-cl-http+instanceNames.lisp
> that is to say, if one is using one of the supported lisp > implementations and one types
> (load #p"<pathname to the load.lisp file")<return>
> at the the repl prompt, one compiles and loads the parser in an > environment without cl-http and in a mode which implements names as > instances (as opposed to symbols).
> which aspect of this prospective process does one find difficult to > understand?
What you describe here is rather easy to understand. I suggest you add it to the webpage
I'm not 100% sure but I think I remember that the last time I checked I was supposed to install CL-HTTP before I could compile CL-XML. That's a bit harder than just (LOAD "load.lisp").
Also, if I unpack the file XML-0-949-20030409.tgz on my machine the "documentation" directory is empty except for three GIFs - no "README" or "INSTALL" file. The file "load.lisp" is just one of five "load*.lisp" files. The fact that it once was a symbolic link obviously got lost in the tarball.
the irony of which is, that page was composed in response to an aversion, from someone who had found the various load*.lisp files, that, once he had looked at them, it was not clear how to load and use the xml-path library rather than just the parser.
> I'm not 100% sure but I think I remember that the last time I checked > I was supposed to install CL-HTTP before I could compile > CL-XML. That's a bit harder than just (LOAD "load.lisp").
it would be helpful to hear what might have led you to that supposition. so far as i can ascertain (i have code going back 4 years only) that has not been the case for a long time. perhpas there's a note somewhere in the documentation which is misleading?
> Also, if I unpack the file XML-0-949-20030409.tgz on my machine the > "documentation" directory is empty except for three GIFs - no "README" > or "INSTALL" file. The file "load.lisp" is just one of five > "load*.lisp" files. The fact that it once was a symbolic link > obviously got lost in the tarball.
hmm. it would appear that i have to be more selective as to which version of tar i use in the future. thanks for the hint.
On Wed, 21 Jan 2004 02:03:33 +0100, james anderson <james.ander...@setf.de> wrote: > Edi Weitz wrote:
>> I'm not 100% sure but I think I remember that the last time I >> checked I was supposed to install CL-HTTP before I could compile >> CL-XML. That's a bit harder than just (LOAD "load.lisp").
> it would be helpful to hear what might have led you to that > supposition. so far as i can ascertain (i have code going back 4 > years only) that has not been the case for a long time. perhpas > there's a note somewhere in the documentation which is misleading?
Hmm, it definitely wasn't four years ago - I hardly knew about CL at that time. It must have been around 2001/2002 and I didn't really try hard to get CL-XML installed. (I didn't need it, I was just browsing.) I read the docs and said to myself "That's too much of a hassle. Let's try again later." (Mind you, that was when I was still fighting with things like MK:DEFSYSTEM and ASDF. I have learned a thing or two since.)
If CL-HTTP wasn't required then maybe the preferred system definition utility (or the one described in the docs) was from CL-HTTP? I can't remember but I know that I left with the impression that I had to be somewhat familiar with CL-HTTP (which I wasn't) in order to use CL-XML. It's good to know that this isn't the case.
* Kenny Tilton | Maybe I just misunderstood. If quads just give me a link to the | parent, well, in the case of the DTD, all the entities, elements, and | attributes had the same parent, the XML dtd document. So I imagined | an awful lot of serial searching, repeated over and over again for the | same message type, and yes, I made a gut determination that I could | use the names of things as keys to a hash table and turn a record | expansion into so many keyed lookups.
You assume way too much. I lack the information to unwind your many assumptions, but you may have noticed that I wrote that QAR would point to the element type, like the operator in the CAR of a sexpr. This is obviously a symbol-like structure. For some reason, you have read what I wrote to refer to the prolog of an SGML/XML document, while I talked about the document instance. I have written elsewhere that the very concept of a DTD was a huge mistake, so I really wish you had asked me instead of running with your assumptions.
Just as Common Lisp is defined on objects in a tree structure, but still manages to have clearly defined semantics, I had hoped it would be rather obvious that I intend the same to hold true for the SGML tree. Defining element types and processors on them is clearly part of the whole approach, and just as Common Lisp systems do not search source files linearly for definitions of operators, this part of the language is not restricted to being represented with quads.
But I don't know where to begin to explain things to you so you don't assume things without asking. It is very difficult to predict what someone who guesses a lot will need to invalidate an assumption.
| Do we need each child to refer to its parent?
Yes.
| Why not a format with the parent first and then one or more children | understood to share the same parent?
That would require more pointers to be kept around in a stack-like structure when traversing the document, while an explicit design goal of my approach is to move all this information into the tree.
-- Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
But one does have to use an "experimental" version of CMUCL, if one uses CMUCL. It's documented on the CL-XML website but I certainly overlooked it the first time I tried to get CL-XML working. It's a CLOS issue, IIRC.
>I know that I left with the impression that I had to be > somewhat familiar with CL-HTTP (which I wasn't) in order to use > CL-XML. It's good to know that this isn't the case.
