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.

///