Re: S-expressions vs. XML
Rich Salz wrote: > > >>Actually, since S-expressions are isomorphic to the basic XML data model, > >>one could argue that X# == LISP :-) > > > > I've heard this claim asserted many, many times, > > but I still don't believe it. > > Let's see, an XML element is > <x attr1=value1...>content</x> > So the attributes are an assoc list, the content is a (recursive) list > of text strings or nodes. That could be represented in S-expr as > (x ( (attr1 value1)... ) content ) > If there are no attributes > (x () content ) That's a reasonable first approximation to g :: XML -> S-Exp. You don't have an isomorphism yet, since the range of g (hence the domain of f) is only a subset of all S-expressions over atoms and strings. But that's fixable. The real problem is that g discards context information, which is an essential part of the XML data model. > For example: > <foo attr='text'><bar>hello</bar><bar a='b'>world</bar>!</foo> > would be > (foo ( ('attr' 'text')) > (bar () 'hello') > (bar ( ('a' 'b')) 'world') > '!' > ) > > > h = XPath(ancestor::*/following-sibling::*). > > Don't have enough neurons to figure out why the above is "tricky." Let x be the text node "hello" in the XML example. Then h(x) includes the element node "<bar a='b'>world</bar>" and the text node "!". There's no f :: S-Exp -> XML that can satisfy h(x) = h(f(g(x))), since g(x) is just the string 'hello'. You can fix this problem too -- it's possible to build *any* data structure out of cons cells and atoms -- but the resulting s-expressions aren't going to look very much like what most people think of when they say XML is just a more verbose way to write Lisp. --Joe English jenglish@f...
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format