From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: XML and lisp References: <3B85106D.C0EFD770@cfmu.eurocontrol.int> <3207626455633924@naggum.net> <3207661527508051@naggum.net> <3207730126705119@naggum.net> <873d6frw7a.fsf@qiwi.uncommon-sense.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3207807028652689@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 70 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Aug 2001 09:30:31 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 998818231 193.71.66.49 (Sun, 26 Aug 2001 11:30:31 MET DST) NNTP-Posting-Date: Sun, 26 Aug 2001 11:30:31 MET DST Xref: archiver1.google.com comp.lang.lisp:14815 * Boris Schaefer > 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: > > 2 > > 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. ///