Subject: Re: XML and lisp From: Erik Naggum <erik@naggum.net> Date: Mon, 27 Aug 2001 05:23:23 GMT Newsgroups: comp.lang.lisp Message-ID: <3207878601378705@naggum.net> * rpw3@rigden.engr.sgi.com (Rob Warnock) > While not repeatable, attributes *are* omissible if the DTD for those > attribute contains either default values or the "#IMPLIED" status keyword, > are they not? That depends on whether you represent the parsed or pre-parsed structure. In a Common Lisp setting, we are dealing with parsed structure. If the attribute value is "implied" in the source, it still needs to be there in the parsed structure. > So if the DTD said: > > <!ELEMENT foo (bar | PCDATA)*> > <!ATTLIST foo bar NUMBER #IMPLIED> > > that is, the "foo" element has an optional "bar" attribute *and* also > allows an arbitrary number of "bar" sub-elements, then (foo (bar 1) (bar > 2)) *would* be ambiguous. If you choose to represent a pre-parsed SGML instance in Common Lisp, I would argue strongly against that before I would even attempt to answer anything else. I _really_ mean it when I say that the attribute list has a fixed length. I also indicated that for pragmatic reasons, I sometimes use a marker to separate the attributes from the contents in the cdr of the element, such as when the task at hand would be wastefully slow if I were to deal with a fully parsed structure. Dirty hacks should be within reach because the world is sometimes not clean. I am probably not going to get used to the habit of some people who see a problem in one part of a proposal and ignore the fact that there is a solution in another part of the same proposal (like the next paragraph), and I am certainly not patient enough with all the rampant idiocy in the SGML/XML world to explain this over and over, but please go back and read the whole message. If you find a need to use a marker in _some_ cases, I have in fact covered it. In the fully parsed, fully general case, that need does _not_ arise, because the attribute list is a fixed set of "slots" in the structure. This should have no bearing on how to process them, however, but of course it matters to and from SGML/XML representation. ///