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

Tight binding with backend systems (Was: What is XML For?)

• To: MSeaborne@o...
• Subject: Tight binding with backend systems (Was: What is XML For?)
• From: "Anupam Singh" <avsingh@h...>
• Date: Fri, 25 Oct 2002 17:15:10 +0000
• Bcc:
• Cc: xml-dev@l...

>So, at least where I work, I get the distinct impression (hopefully false) 
>that organisations are actually wanting the data interchange format to be 
>what they build new back end systems over, so they don't have to do bother 
>with any transformation. This seems an amazingly short-sighted, and 
>dangerous thing to do. A technology touted as an aid to loosely coupling 
>disparate applications, is, ironically, leading to tighter coupling than 
>existed before.

Does this tight binding mean that the only way customers can make
XML work for them is by pushing the XML transformations into their
persistent/proprietary data-store? Is this because they think
on-the-fly XML transformation tools/products (or homegrown solutions)
are not efficient enough?

regards,
anupam






>From: "Mark Seaborne" <MSeaborne@o...>
>To: "Paul Prescod" <paul@p...>
>CC: "xml-dev" <xml-dev@l...>
>Subject: RE:  What is XML For?
>Date: Fri, 25 Oct 2002 08:49:13 +0100
>MIME-Version: 1.0
>Received: from mail.oasis-open.org ([209.202.168.102]) by 
>mc1-f4.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 25 Oct 
>2002 00:49:04 -0700
>Received: (qmail 7082 invoked by uid 60909); 25 Oct 2002 07:58:19 -0000
>Received: (qmail 7074 invoked by uid 0); 25 Oct 2002 07:58:18 -0000
>Mailing-List: contact xml-dev-help@l...; run by ezmlm
>Precedence: bulk
>X-No-Archive: yes
>List-Post: <mailto:xml-dev@l...>
>List-Help: <mailto:xml-dev-help@l...>
>List-Unsubscribe: <mailto:xml-dev-unsubscribe@l...>
>List-Subscribe: <mailto:xml-dev-subscribe@l...>
>Delivered-To: mailing list xml-dev@l...
>content-class: urn:content-classes:message
>X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
>Message-ID: 
><DC65AE678B89004B9CCB202E19482CC704FB3A@m...>
>X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic:  What is XML 
>For?
>Thread-Index: AcJ7hikxL7LkXQbwSnqYI4BNTkotgQAcT3jQ
>Return-Path: xml-dev-return-16307-avsingh=hotmail.com@l...
>X-OriginalArrivalTime: 25 Oct 2002 07:49:04.0670 (UTC) 
>FILETIME=[FD9C13E0:01C27BFA]
>
>Where once we would design EDI (EDIFACT) messages, now we design XML 
>messages. XML is just fine for representing the kind of hierarchical 
>structures that EDI uses. I don't know that it does a better job of it than 
>EDI, but it has the advantage of being ubiquitous.
>
>On the other hand, XML actually can have a big disadvantage over EDI, the 
>same one that is its main advantage, actually. Not many people ever thought 
>of using EDI everywhere, for for anything; it is okay over the wire, but it 
>is normally transformed into something more malleable as quickly as 
>possible, once received. In theory XML is a step up from EDI, because there 
>is a whole raft of tools available to help you to transform it.
>
>Unfortunately, some organisations appear to be taking the position that 
>because XML is now usable in every tool under the sun, that not only should 
>it be used everywhere, but it can be used everywhere as is. So, at least 
>where I work, I get the distinct impression (hopefully false) that 
>organisations are actually wanting the data interchange format to be what 
>they build new back end systems over, so they don't have to do bother with 
>any transformation. This seems an amazingly short-sighted, and dangerous 
>thing to do. A technology touted as an aid to loosely coupling disparate 
>applications, is, ironically, leading to tighter coupling than existed 
>before.
>
>I think this problem is exasperated by organisations such as the one I work 
>for. If you sign up to use a standard within your vertical industry, and 
>send people along to committees to influence message design, you get a 
>false sense of being in control. This will presumably evaporate once member 
>organisations begin exchanging data with organisations outwith the 
>standards body, who refuse to use our standards. That'll learn 'em.
>
> >Paul Prescod wrote:
>
> >XML is weird for business data? Did you ever work with EDI?
>
>EDI isn't weird, it is actually very simple, it just looks terribly 
>complicated. For a company wanting to sell EDI based software this is a 
>godsend. The software is fairly trivial to put together, but because EDI 
>looks hard to your average consumer, it is quite easy to convince them to 
>part with lots of money, firstly to use the software, and secondly to have 
>someone else set it up and maintain it for them. This gives the software 
>vendor a nice, steady stream of recurring revenue for hardly any work.
>
>XML has suffered from the problem of looking too simple to the user. Whilst 
>this has helped uptake, users of XML expect to get it for free, or less. 
>Fortunately a lot of people are putting a lot of effort into making XML 
>seem as hard as EDI, and I think their efforts are beginning to pay off.
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>


_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

• Prev by Date: [ANN] Tool to translate XML Schemas into ASN.1 modules
• Next by Date: Re: Re: Living Documents (Was: We need SAX etc ..)
• Previous by thread: [ANN] Tool to translate XML Schemas into ASN.1 modules
• Next by thread: Re: Re: Living Documents (Was: We need SAX etc ..)
• Index(es):
  • Date
  • Thread