From ...
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail
Newsgroups: comp.lang.lisp
Subject: Re: XML and lisp
References: <g07kvvjf1z.fsf@scumbag.ecs.soton.ac.uk> <3207730126705119@naggum.net> <873d6frw7a.fsf@qiwi.uncommon-sense.net> <3207807028652689@naggum.net> <9mavnn$ec8ip$1@fido.engr.sgi.com>
Mail-Copies-To: never
From: Erik Naggum <erik@naggum.net>
Message-ID: <3207878601378705@naggum.net>
Organization: Naggum Software, Oslo, Norway
Lines: 42
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 27 Aug 2001 05:23:23 GMT
X-Complaints-To: newsmaster@Norway.EU.net
X-Trace: nreader1.kpnqwest.net 998889803 193.71.66.49 (Mon, 27 Aug 2001 07:23:23 MET DST)
NNTP-Posting-Date: Mon, 27 Aug 2001 07:23:23 MET DST
Xref: archiver1.google.com comp.lang.lisp:14892

* 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.

///