[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: heritage (was Re: SGML on the Web)


heritage java
Patrick Durusau wrote:

 >> XML's lack of a data model is a deliberate, careful design decision,
 >> and the evidence of recent years is that it was correct.
 >
 > I obviously disagree but was wondering if there is a record of this
 > "deliberate, careful design decision" in canonical or non-canonical
 > documentation about the drafting of XML? (If enforced nesting of
 > elements is not a defacto data model I am not sure what definition is
 > being used for data model. Not using the words "data model" does not
 > make it any less a data model.)

Well, the syntax of XML certainly puts constraints on what kinds of data
models you can reasonably use for it; but we've already seen a
remarkable variety of approaches, even in small subsets of the universe
like Java XML APIs.

As for the decision, it was all over in about 45 seconds on one
teleconference, I remember it clearly.  Fairly early on in the XML
design process.  Someone (maybe me? I forget) said "er, should we do an
API as well?"  and James Clark said "isn't the idea that there's going
to be one API that's going to work for all the different things you want
to do kind of silly?" and everyone said "oh, right" and that was that.

Below is a rant I wrote on this subject to a mailing list some years ago 
and have regularly re-posted. -Tim

=====================

It took me years to realise how deep and important the divide is between
wanting an SDK and wanting to know the underlying protocol.  Too much of
our biz can only see one of these realities.  I grew up with networked
minicomputers and (mostly) Unix, and maybe that's why, in the final
analysis, I always want to see the bits on the wire, because in the final
analysis, given any programmable device, I can work with them.

XML is of course the ultimate expression of that philosophy; it can
do a reasonably good job of offering a bits-on-the-wire view of just
about anything.

During the heydey of client-server I was repeatedly baffled and frustrated
by the mind-set, in particular evidence chez Apple and Microsoft, that the
only expression of computing reality was a big hairy complicated API with
an associated big hairy complicated (and often expensive) SDK.  This is not
just a Unix-vs-PC thing - the X window system is one of the most extreme
examples of the big, hairy, complicated, API (the rumor that they ever
actually fully documented the wire protocol is false).

And not that this approach is wrong - I'm sitting in front of Windows
box, and three of the windows are X applications running on my
big server which off at a distant ISP.

These days I write big complicated software in Java, which does a good
job of giving you a tractable object model overlaying insanely complex
infrastructure.  But in a distributed int{ra,er}-net scale app with
heterogeneous boxes, there's still no substitute for the bits on the wire.

Our profession needs to grow up a bit and actually arrive at a
consensus as to when each of these approaches is appropriate, teach it
in college, and so on. -Tim



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.