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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Interesting Monday.

[ Lists Home | Date Index | Thread Index ]
  • From: "Matthew Sergeant (EML)" <Matthew.Sergeant@eml.ericsson.se>
  • To: "'Tyler Baker'" <tyler@infinet.com>, "'xml-dev@ic.ac.uk'" <xml-dev@ic.ac.uk>
  • Date: Tue, 2 Feb 1999 10:05:29 +0100

> -----Original Message-----
> From:	Tyler Baker [SMTP:tyler@infinet.com]
> Sent:	Monday, February 01, 1999 5:57 PM
> To:	Matthew Sergeant (EML)
> Cc:	'xml-dev@ic.ac.uk'
> Subject:	Re: Interesting Monday.
> 
> "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.
> 
	I think you've missed my point all together here (correct me if I'm
wrong). Much e-commerce in the future is going to be done using XML. For
e-commerce to work you have order-generators (the web-shop) and transaction
processors (the credit card company, or someone who processes the order).
Generally these aren't the same company. The transaction processing
companies will have their work cut out for them performing hundreds of
transactions a second using XML. That's all I'm saying. How they get around
that is their business. (it might even be my business in the near future,
just not now).

	Matt.

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





 

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

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