OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   toxins/tocsins (was RE: [xml-dev] XQuery and DTD/Schema?)

[ Lists Home | Date Index | Thread Index ]

At 06:16 PM 7/3/2002 -0700, Derek Denny-Brown wrote:
> > -----Original Message-----
> > From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> >
> > XML is a wonderful set of tools for marking-up information with
>labeled
> > structures.
>
>XML is a wonderful tool for (a) marking-up textual data and (b) interop
>of 'data', typically serializations of either relational or object
>structures.  I work with people using XML to great success for both
>purposes.  Both purposes have alternate solutions, which may be better
>in some cases, but for whatever reason XML has been chosen as the tool
>of the day.  SOAP ensures that huge numbers of people, and mostly people
>who would never invest the time to join xml-dev, will fall into the (b)
>camp above.  I express no opinion on whether SOAP as XML is good or bad,
>but it most definitely _is_.

I believe that SOAP is using XML because of the lingering hype wave from 
XML, not because XML itself is particularly well-suited to the tasks that 
SOAP performs.  I'd say SOAP used HTTP early on for similar reasons, and I 
hope that just as SOAP appears to be leaving HTTP behind as it becomes 
clearer that SOAP and HTTP have little to do with each other, that SOAP may 
yet leave XML behind.

>Many people in the (b) camp see XML as an abstraction.  They could care
>less about the syntax, but are looking for a tool to pass information
>between systems such that they can leverage many existing tools to
>process that information along the way.  The (b) camp typically involves
>files where no human ever sees the data.  All they care about is interop
>and tools.

It's time to start telling the (b) camp that they're living a lie.  It's 
not merely a matter of whether or not humans see the data, or whether the 
information is data or documents.  The problem comes from the mismatch 
between the structures in XML and the structures they want to abstract.

You can force any structure you want into XML, pretty much.  The results 
are likely only useful to tools that like that particular 
structure.  Representing information in XML is very different from cramming 
information into XML using a set of tools which just convert an existing 
set of structures into an XML representation.

I think XML is a great format for representing data, not just 
documents.  At the same time, however, I think that people who want to use 
XML for the data need to think about how XML contains and describes 
information, much the same way that people who use objects or relational 
databases have to consider such issues.

Right now, it seems that most of the W3C projects affecting these areas - 
W3C XML Schema, W3C XML Query (and its fallout in XSLT and XPath) - have 
pretty much lost touch with the notion of using elements and attributes to 
label information, and instead are blurring object and relational notions 
with XML syntax.  I don't believe that's sustainable.

>DTDs provided a moderate solution to (a) and simple cases of (b) above,
>but failed miserably for complicated (b).  RELAX NG is hugely better,
>and is an elegant solution to validating that an XML document which was
>received (be it scenario (a) or (b) ) conforms to your expectations.
>Where both DTDs and RELAX NG falter, is integrating the XML solution
>into the OOP/Relational world that is the rest of the application.

The rest of the application is the rest of the application, something to 
keep separate from the markup rather than cram into the core.  Building 
applications responsibly commonly requires some thought about how to use 
technologies effectively.  OOP and relational databases have had mismatches 
for years, but the answer hasn't been to force objects into tables or 
tables into objects.

> > RELAX NG makes me think of a set of houses built to fit in their
> > environment, with minimum impact on the surrounding terrain.  W3C XML
> > Schema makes me think of a subdivision built by clearcutting the area
>and
> > then building houses according to plans that worked well enough
>someplace
> > else.
>
>But what if those houses are designed for people from that someplace
>else?  They expect their new houses to be similar to their old houses,
>to work in similar ways.  Mankind has a long history of doing exactly
>this, and pounding that square peg until it fits, by a bit of both
>shaving off some edges and stretching out the whole.

Then perhaps it's time to tell those people to go back to that someplace 
else until they have some notion of how best to fit into the terrain rather 
than forcing it to fit them.  It's wonderful to have a house in the woods, 
free of building codes but packed with the latest goodies.  Wonderful, that 
is, until the fires, mudslides, or other disasters show up.  Funny how 
"natural disasters" often have much to do with humans refusal to 
acknowledge their impact on the landscape.

>Just because those traditional XML notions have been around for a while
>does not mean that they are the only way to view things.

Just because those traditional OOP notions have been around for a while 
does not mean that they are the only way to view things.

Just because those traditional relational databases notions have been 
around for a while does not mean that they are the only way to view things.

>Relational and OOP oriented people are trying to use XML, and will
>continue to do so.  Work with them, not against them.

They're not trying to use XML.  They're trying to do what they always have 
done, and bolting it on to a syntax that doesn't match their persepective 
very well. They are taking a set of tools which works very well one way, 
using it poorly, and then claiming that result is the way it should 
be.  It's long past time for open conflict.

>You can ignore the portions of WXS which don't fit your application.  If
>that leaves a core that does not meet your demands, then you should
>provide specific feedback to the WXS 1.1 committee about what is
>missing.  Just because it allows you to do things which are bad, does
>not mean that it is bad.  C allows me to dereference a NULL pointer and
>crash my program, so is it a bad programming language?

I can't ignore WXS at all.  It's damaging the technological landscape of 
XML, not merely providing tools.  It's infesting other XML-related specs 
with grotesque results.  I used to think WXS was a cancer, but I've shifted 
perspective.  It's an environmental disaster with people behind it who 
simply don't care about its impact or even believe that such an impact exists.

>Dredging up the ancient document vs data debate... WXS attempts to
>satisfy the perceived needs of both camps.  Where if fails, it should be
>corrected.

It's not a simple documents vs. data debate.  It's that WXS has pretty much 
no sympathy with or understanding of the underlying markup structures.  The 
difficulty of adding an attribute to a simple element seems like a poster 
child for the level of mismatch.

>I sincerely wish WXS could have been based on a validation framework
>like RELAX-NG combined with distinct object layer, but it wasn't.  C++
>is not perfect either, but has become a rather popular.  It is not just
>that it was better than the alternatives.  It was that it fit into the
>existing frameworks, etc..  WXS has already been accepted as part of
>many XML frameworks, so lets work to improve it.  Starting from scratch
>always looks easier, but then runs headlong into troubles when you
>attempt to interoperate with existing frameworks expecting the old.

WXS is itself a "start from scratch" phenomenon, and constantly "runs 
headlong into troubles when you attempt to interoperate with existing 
frameworks expecting the old."

>I'm not trying to parade a company line, and am one of the people 'round
>here who have held that WXS has some serious problems, and RELAX-NG has
>some good insights.  I just try to be a practical person, and experience
>has taught me that the elegant is not always the winner.  Given a
>choice, I'd be writing much of my code in lisp or sml, not C++.  That
>choice would mean that my solutions would help multiple orders of
>magnitude less people.  I'm here to make solutions for people, so I live
>with #define and other ugliness.  In return I go to conferences and hear
>people talk about how they used my software to solve real-world
>problems.  That just feels good.

Enjoy the warmth for now.  There's a lot of ugliness yet to come, as the 
mismatches between what XML is sold as and how it actually works come to 
the surface.  The lack of "elegance" isn't the problem.  Lack of common 
sense and a serious dose of impatience are much larger problems.  Those 
aren't typically hallmarks of practicality.


Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS