[
Lists Home |
Date Index |
Thread Index
]
On Mon, Dec 17, 2001 at 01:57:32AM -0800, Dare Obasanjo wrote:
| > At the end of the day code and data just aren't that much
| > like each other. Maybe this is why Lisp never took over the
| > world, cool though it is. -Tim
|
| It is very interesting that you say this. I've seen a few people
| from the Lisp camp complain that XML is simply a more verbose yet
| less powerful reinvention of Lisp S-expressions with a lot of
| extra complexity added in (like namespaces, attributes and
| entity references). I assume this is what led the proposal of
| Minimal XML by the SML folks.
It is important that a serialization language accomplishes
two goals simultaneously. First, it must represent the
structure of the information being serialized. Second,
it must do so in a way that is human readable.
For document markup, where you need out-of-band information,
attributes and mixed content are essential. In this field,
Common XML excels (although I would say that SGML's optional
tag rules would make the texts even more human readable).
| Being primarily from a database and distributed computing
| background, I'm interested in XML primarily as a data
| storage/serialization format so I see it primarily as data
| thus when I see things like XSLT and XQueryX, I can't help
| but think that the Lisp folks may be right about XML and
| it's relationship to Lisp S-expressions.
It is this domain, data serialization that I think XML
is sub-optimal. In this case, mixed content is rarely
useful and attributes cause more confusion than they
help. Mixed content can be modeled as a list of maps,
and attributes can be made into full-blown elements.
This is clearly seen with RELAX-NG, which minimizes
the difference between elements and attributes.
When working with Minimal XML (in practice), I found
the primary construct, a sequence of named elements,
to have a high dissonnance with both relational databases
_and_ most programming languages. I then dug heavily
into SOAP, where the semantics required by programming
languages are layered on top of XML. In the end, however,
this makes SOAP very complicated. The SOAP user must
respect all of the rules of XML (which were designed for
structured documents), the SOAP restrictions on XML, and
then the additional SOAP constructs.
Certainly SOAP meets the requirements of serialising
data structures from programming languages, however,
I feel it does so at a very heavy cost to readability.
Furthermore, this bolting leaves SOAP systems with
a rather indeterministic information model and XML
tools (XSLT) which must be used very carefully in
order not to violate the SOAP schema. This is
further complicated since there are application
schemas which must further be layered on top of SOAP.
That said, I'm a big SOAP fan. It has enabled me
to do the things that I need to get done. However,
SOAP has lead me to to co-develop an alternative,
which I hope you all may one day find useful. It
is called YAML, and it strikes what I believe is
a sweet spot for data serialization. Since I view
XML as primarly a structured document serialization,
I don't see YAML as competing with XML, as much
as it competes with SOAP.
You can read more about YAML at http://yaml.org,
the current working draft specification is at
http::/yaml.org/spec. It is relatively stable
now and we don't expect any huge changes in
the syntax or information model. Sometime
early next year it will become a release canidate,
and a few implementations will follow. Currently,
Brian Ingerson has written a Perl implementation
and I'll be working on the C implementation as
time permits. Right now I have a hobbled
Python implementation of YAML which works
wonderfully for my particular needs.
I hope this is helpful,
Clark
--
Clark C. Evans Axista, Inc.
http://www.axista.com 800.926.5525
XCOLLA Collaborative Project Management Software
|
