Subject: Re: XML and lisp
From: Erik Naggum <erik@naggum.net>
Date: Sun, 26 Aug 2001 09:30:31 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3207807028652689@naggum.net>

* Boris Schaefer <boris@uncommon-sense.net>
> Well, I agree that in most cases you will know whether something was
> an attribute or contents, when you're processing it, but what about:
> 
>   <foo bar="1"><bar>2</bar></foo>
> 
> If I understand you correctly (and I'm not exactly sure about that),
> you would represent this in Lisp as:
> 
>   (foo (bar 1) (bar 2))
> 
> I don't see how you can distinguish attributes and contents in this case,
> and how you can translate this back into the same XML.  Probably I'm
> missing something.

  Yes, you are definitely missing the constraints of SGML in real life.
  There are some problems that are not worth solving because they never
  come up even if they superficially could appear to come up if you do not
  pay attention.  This is such a problem.  You have failed to consider the
  ramifications of the solutions and pose a problem that simply would not
  exist if you did.  This taxes my patience, which already legendary in its
  general absence.

  However, I apparently need to insist that you understand that in SGML and
  XML alike, you do in fact know what attributes an element has.  It cannot
  possibly be ambiguous.  If you decide to name a sub-element the same as
  an attribute, however massively stupid that is even with SGML/XML as it
  is, you _still_ know that you have an attribute with that name.  That
  there is a sub-element with that name, as well, is coincidental to the
  representation.  There simply is no way you can _not_ know that, unless
  you go out of your way to destroy the information that SGML provides you
  with.  If you destroy the information that is available to you, you will
  not get me to do stupid human tricks answering your resulting questions.

  I truly wonder what is so hard to understand about this.  We Lisp people
  are quite used to association lists, right?  Keyword-value pairs do not
  need to be in property lists to be understandable by Lisp people, do
  they?  To my mind, whether you store something in a property list or an
  association list is arbitrary.  However, in the reactions that I have
  seen to obliterating the false dichotomy between attributes and contents
  in SGML, there somehow seems to be a _fundamental_ difference between
  property lists and association lists.  I completely fail to understand
  how that can be.

  The whole deal is so simple I do not even know how to explain it so
  people get it if they do not get it immediately.  It is somewhat like
  seeing someone struggle with fractions.  They either get it or they do
  not, and although I have managed to make many a struggling child get the
  idea, I have _no_ idea what precisely caused them to grasp it.  It just
  happened, and they laughed in relief.  This attribute/container thing is
  equally intuitively evident.

  Case in point: An element has a fixed number of attributes.  That is
  reflected in a fixed length of the association list that makes up the
  attributes.  Attributes are not repetable and not omissible, so if there
  are n attributes in the attribute list for an element, there will be n
  conses with attributes in the cdr of the element representation.  There
  are no two ways about this.  It is completely and irrevocably unambiguous.

  By exploiting the rich information we have about the elements and their
  makeup in SGML, we can reason about things with much simpler means than
  by adhering strictly to the particular representational issues in SGML.
  If it matters to you that some values are attributes, you ask for the
  attribute information.  If it does not matter to you, you can be relieved
  of the distinction.  If you want to transform attribute to contents or
  vice versa, modify the information about the element, not the element; if
  and when you print it out, the modifications will manifest themselves in
  new SGML/XML syntax, but nothing happened to your internal representation.

///