RE: XML - where's the beef?

["David B. Stewart" <dbstewart -at- dswrite -dot- com>]

>>The systems currently invested
in SGML are only waiting for a compelling reason to convert over to XML.
  The initial aim of XML (if I'm not mistaken) was to sort of dumb down
SGML...<<

I can't address an SGML-to-XML comparison as I'm not at all familiar with
SGML.  My experience as a software engineer and project manager leads me to
believe the aim of XML is much broader than to merely dumb down SGML.
Systems that must exchange data on any level, not just B2B, often require
massive and expensive conversion and translation efforts due to the large
number of data "standards" and formats in use (or in existence, as
historical data frequently must be converted from extinct "standards" or
proprietary formats).  This occurs daily in medical records, billing, claims
verification, sales, banking, modeling, you name it...any transaction
between databases.

Each business has its own "standard" for data formatting and transmission
(e.g. HL7, LIS, et al).  Each profession believes it must have a unique
method and format as its data are truly different from any other.  Slow or
expensive technologies of the past often weighed-in on this view.  Most have
"free form" options that too often defeat the purpose of standardization.
The effort required to handle cases of extracting and managing common data
elements is too frequently monstrous.

Enter XML.  An ASCII-based, fat, flat file format.  Old hat.  The stuff
programmers would have been laughed out of the profession, demoted, or fired
for developing not so many years ago because of slow processors and
expensive storage.  My first thought is to compare it to ASN.1, a basis for
network management data.  It's big.  It's flexible.  It's widely understood
and generally human readable.

XML is not fresh.  It is not altogether bad...or good.  It is re-application
of old ways.  It is flexible.  That fact alone will cause a lot of grief due
to inept designers.  In competent hands it may help business.  It will cost
billions of dollars for system upgrades, schema conversion, and re-coding or
replacement of applications and interface engines (contrary to much of the
marketeering poop being spewed by XML proponents).  So what's new?

If XML can be effectively used as a single source for documentation, data
warehousing, EDI, etc., the pain may be worth it.  Businesses will need
sound advice from professionals who are willing to understand and weigh the
good and the bad.  Those with deep understanding of general markup languages
should be at the forefront of the discussion.

Technical communicators may be a prime group to fill that need.  However,
they won't fill it by touting their writing skills or applying only those
aspects that fit documentation.  It's time to tech up.

>>As for the future - one impediment to XML as a standard for B2B is
bandwidth...<<

The thought that XML may kill Java is premature.  I believe each will find a
niche and survive, but it is too early in the game to say.

As a network engineer for the past 12 years, the bandwidth issue is pure FUD
(fear, uncertainty, doubt).  There is no need for more bandwidth because of
XML alone.  That is too common an excuse for all that ails recent
technology.  Most bandwidth issues are due to incomplete or inept design and
planning.  Stupidity (nay, not even ignorance) is the prime cause of network
troubles.

>From all I've seen, XML is plain text. Just like HTML.  It is easily
compressed.  It is easily fragmented.  Foolish designers and programmers
will dump gargantuan data streams that may require high bandwidth.
Experienced designers and programmers will develop "network friendly"
applications.  Such experience exists, but it is not in the majority.

Such friendliness is not possible in many cases today as many common
database formats and engines (the over-the-counter variety) are incapable of
delivering data or query results in small quantities.  They were designed
under assumptions of LAN bandwidth and are detrimental to most (affordable)
wide-area network architectures.  An "If you build it, we will exhaust it."
mentality.  Human nature.  Stupidity.

I believe XML can (and will) be leveraged to resolve such issues.  Back-end
applications will develop necessary compression schemes or they may not be
feasible for deployment to any but the largest corporate backbones.  Cost
will decide.  Wise technologists will work to develop (not just talk about)
the cost saving side of XML arguments.

My $0.20 (inflation, you know).

Regards,
Dave Stewart
http://www.dswrite.com/


-----Original Message-----
From: bounce-techwr-l-71190 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-71190 -at- lists -dot- raycomm -dot- com]On Behalf Of Chris
Despopoulos
Sent: Thursday, May 31, 2001 4:15 AM
To: TECHWR-L
Subject: RE: XML - where's the beef?


One thing most folks seem to forget about whenever XML is the topic -
SGML.  In fact, there's plenty of information already in SGML, and
already used to great advantage.  <big snip>


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See
http://www.infomap.com or 800-463-6627 for more about our solutions.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.