Gavin writes,
[snip...]
>First of all, let's look at the example document from the first article
that
>Glenn pointed out:
>
><?xml version="1.0"?>
><list>
> <recipe>
> <author>Carol Schmidt</author>
> <recipe_name>Chocolate Chip Bars</recipe_name>
> <meal>Dinner
> <course>Dessert</course>
[snip...]
>The above example is not written in XML, it's written in another language
>which might be named "RML", the Recipe Markup Language. These RML
documents
>will only be useful if there are other systems in the world which speak
RML.
>Do you think your cell phone is ever going to understand RML?
[snip...]
>All of these marvelous examples of XML that I've seen stop short of
actually
>*doing* anything with the data once it gets to its destination. Usually
>they feed the file and DTD into an XML parser which presents the result as
>an expandable tree structure in a window. Whoopee. Why don't I just write
>out my data in English and send it in a text file since it will be just as
>easy to view?
First of all, let me stake my flag to the pole...I'm a big fan of XML. It
does its job remarkably well, and I've been doing it long enough (over 18
months) to be able to recognise much of *what* it does (and much more of
what it *doesn't*). This could be much harder now for newcomers given the
huge mass of hyperbole!
It is correct that cell phones are not going to recognise RML, even if they
can currently recognise WAP (a derivative of XML)...now. (In the future
they
may well once they have Java Virtual Machines in them, but I'm no
Cassandra.)
But for the example given, I could equally write it out in HTML, and despite
a browser rendering it, it also won't be *doing* anything. But this doesn't
mean that HTML is not valuable. It is just that the example has no meaning
or interest to me. But, if my business was selling recipes, XML would be
there.
What XML attempts to do is provide information about your data. A
text document tells me little or nothing about the relationships of one
piece of data in a document to another. Because of the hierarchical
structure of XML documents, the user of that document can determine
/context/.
Now of course it would be silly to think that XML is doing something never
done before. HTML can be considered a specific implementation of XML using
a fixed definition agreed to by W3C and browser-makers. While doing a good
job for computer to user communication, it is too fixed, too rigid for
computer to computer communication. Insufficient context.
More often than not, in the "old days", we frequently kept the
context of the data in the program. This is still the most efficient for
space and processing minimisation. But this too is rather rigid and can be
costly
(in time & money) to create new and implement. There is the issue of
supported
environments...switching from 16 bit to 32 bit tended to break the code, as
probably will moving from 32 to 64 bit. In re-writing, it was difficult to
ensure the context or logic wasn't altered, especially after 6 to 12 months
elapsed.
Similarly, I too have written custom 'tagged' formats, or predicate parsers
which evaluate data both in text and binary formats. Even with these more
adaptable formats, it was not uncommon for a little of the context to again
slip
into the logic of the program. It was easier to code
[AFTER THE TITLE READ FROM 1 TO 10 AUTHORS NAMES],
than ensure a self-describing method that would permit from 1 to 'n'
authors. Others, I'm sure were more disciplined, but it is nonetheless
difficult.
The beauty of XML is not only that it provides a fairly robust means for
describing a hierarchical structure that is independent of the program using
it, but that there are also a set of readily available tools available for
their use. The parsers and lexical analysers don't have to be written from
scratch. There are implementations that already work for C, C++, Java,
Delphi, Python and others, most at no or negligible cost. Why re-invent the
wheel.
In all but a few exceptions, most companies are now in the information
business. This means that what they are selling is based on information
they *know* rather than abstract creativity. In most organisations, most of
this information is locked in between the ears of their employees. However,
more and more effort is being made to hold this information in external
sources...documents, spreadsheets, web-pages, memos, diagrams, etc.
However, if I write a document in Word, and put a phrase in italic, or wrap
quotes around it, the reason why I have done so may be lost. And while a
human reader may be able to understand it, most computer systems reading
that document wouldn't. Or else I have to write very large and complex
programs that mimic the human brain in their ability to derive context and
meaning. Using XML, on the other hand, provides me a way to pass that
meaning into the document. In fact, XML is primarily concerned with the
meaning, not the presentation.
Your need to use a standard such as XML for connectivity to your system is
probably inversely proportional to your market share and dominance. If you
hold the market, you can specify the rules. If you are a small player, then
you will want to use standards as a way to make the challenge against the
big players a little more balanced. I suggest that there are many more
small players than big players.
In the health industry, for example, and hospitals in particular there is a
common need to pass information between different computer systems using
software of different suppliers. Emergency Department/Trauma systems
connect to the Patient Accounting Systems (PAS), Pathology systems,
Radiology systems, Biochemistry systems as well as external bodies like
State and Federal Departments of Health. Originally most of these systems
had proprietary interfaces to external systems (based on their market
dominance). Common information like a patient demographics (Identifiers,
Name, Address, Next of Kin, Next of Kin's Address, Doctors, Doctors'
addresses, Doctors' identifiers) was handled in a huge variety of ways.
Over the last 4 years, I've coded over 14 different facilities for getting
this information from different suppliers. The techniques include multiple
DLL calls, network connections to remote character based processors, screen
scraping and direct database calls (to database emulation systems). It was
a nightmare, especially has hardware or network topologies changed in
hospitals.
Fortunately, as no one player has a majority in all sectors, the giants
eventually had to agree to a common means of describing this information. A
standard was developed, Health Level 7 (HL7) which attempted to bring these
things together. A specific syntax was designed, and then various coding
rules for record sets was developed. Again it was Ascii based, and it
supported heirarchical data (but only to one level), but it came with no
tools. While a huge step forward over proprietary interfaces, it still
created difficulties as programmers tried to map their knowledge of the data
into a rigid, externally described data definitions. And complications came
when it was applied to environments beyond the US-based standards
organisations, like in Australia and the UK.
So it is not surprising that the HL7 group now is adopting XML as the next
evolution of the HL7 standard. Variations in locality can be handled with
namespaces. XML provides much more flexibility plus the tools to make such
adoption easier. Pervasive computing is the goal, with XML as an important
contributor.
Is XML the spawn of Satan? No way.
Will XML make my clothes cleaner, my teeth brighter, and cleans the gray
away from my hair? No way.
But just as ASCI helped make representation of character data consistent
between applications and systems, XML will make representation of
hierarchical data between systems easier. It is an enabling technology to
assist in the better design of /some/ computer programs.
Jim Wowchuk [log in to unmask]
Vanguard Computer Services P/L
_--_|\ Post: PO Box 18
/ \ North Ryde NSW 1670
\_.--._/ <---Sydney NSW Phone: +61 (2) 9888-9688
v Australia Fax: +61 (2) 9888-3056
|
