[
Lists Home |
Date Index |
Thread Index
]
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@flightlab.com
|
