Interesting Monday.

[Tyler Baker]

"Matthew Sergeant (EML)" wrote:

> Boy, you people sure can write when something stirs you up... It's 10:10am
> and I've only just got through my backlog of XML-Dev mail...
>
> Well, as the person who introduced the topic "Will XML eat the web?", I feel
> I should just add some points of note. I thank everyone who has contributed
> to this topic though.
>
> Firstly, I think there is still an issue with processing power and XML,
> although I can see that my system is poorly designed. Time for a rethink...
> The area where I can forsee potential problems is in e-commerce. Take an
> e-commerce transaction processing company that's moved to an XML transaction
> format. They don't have a shop web site, they just process credit card
> transactions for other sites. I imagine they are going to need to process
> hundreds of transactions per second. I don't for a second suggest that they
> store the XML as the primary data format (store it as a backup as suggested
> here) - it should immediately be put into an RDBMS. But to do that they have
> to parse each transaction. There's no caching that can go on here.

There seems to be a major misconception here I think in terms of what software
needs to do for businesses.  The issue for XML I think should be scalability, not
just raw speed.  What use is the XML/XSL architecture if it costs mucho deneiro
in development dollars for fly-by-night consultants, overpriced databases, and
application servers.  Maybe some giant bank has money to burn, but the average
web-shop if they are even profitable is running their business on very thin
margins.  Raw performance of using XML is not what should be the focus here,
simplicity should be the focus.  Using XML for backup or log files is not a bad
use of XML.  In fact it is a very simple use of XML to do some very simple
things.  What major benefit is XML other than through some document API like the
DOM if it is stored in the DBMS.  Are you going to have the DBMS construct an XML
stream on the fly which then needs to be reparsed into some in-memory data
structure like the DOM to do anything useful with it at the server level.

> Luckily that's their problem and not mine <g>.
>
> My problem was slightly different. I needed to be ready for the 5.0 browsers
> (probably IE5, although I'd prefer NS5), and XML seemed ideal because we
> would be displaying/editing documents that look like data (or data that
> looks like a document if you like). We really needed an object database, but
> I needed to get moving quickly (a typical web project: "Can we have it
> yesterday"). Learning an object database wasn't a possibility. I already
> knew XML. So I looked at it like this - we could have it 2 ways:
>
> 1) Store XML now, process into HTML now, Transmit XML in the future.

Basically to do this you will need in effect a flat-file database.  I think a lot
of people who will be using XSL will be doing things this way.  Just write some
XML file by hand that contains your data, apply a stylesheet, and voila! you have
HTML.  Transmitting XML does no real good unless it is in some document format
the browser understands.  Even then you will probably want to use XSL to spit
content out into this presentation format.  This can be done at the server-level
or else in the web-browser.

> 2) Store in RDBMS now, process into HTML now, process into XML in the
> future.
>
> #1 looked like a nicer solution because it gives performance gains in the
> future, which #2 doesn't really (except perhaps XML is a lighter weight
> format to transmit than HTML). However this, it appears, is not the right
> way to go because RDBMS->*ML is always faster than XML->HTML. That's a
> lesson learned, and I thank you for it.

Of course this is under the assumption the browser has XSL capabilities and that
they are compliant (MS XSL for instance in IE5 is not exactly what you would call
compliant XSL at the moment).

> Some of the points about caching are great when you're reading 1 XML file
> multiple times, but we're talking about 400 - 1000 XML files being accessed
> and constantly changed. A nicer solution would be an OODB. It's probably
> time to go shopping...

Of course.  My previous comments were under the assumption that the XML content
was pretty much static.  Nevertheless, using an OODB will not necessarily give
any benefits over an RDBMS.  It all depends on your particular business problem.
I will let the fight of "whose database is better" up to the DBMS vendors.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)