Erik [e]Vistica writes:
>After skimming through Bruce Toback's reply (good info, thanks) I now
>have a revised analogy (beyond copylib/fixed record).
>
>Sounds like Self Describing (SD) files (I believe that Robelle
>makes/made use of these. An age old paper comes to mind. Anyone at
>Robelle care to comment?) I think Query uses them too (I never got into
>the details).
SD files started with Query, but over the years, Robelle has sort of
become the custodian since they've published the only documentation.
>Or, for data transfer, create an Image database with a single
>stand-alone
>Detail dataset and the receiver can make DBINFO calls to their heart's
>content. (Yeah, I know, not an open-system approach).
This illustrates the difference between XML and any of the other schemes
mentioned so far. XML can represent hierarchical data in true
hierarchical form. It's like sending a whole database and schema, not
just a data set, and sending documentation on the logical relationships
between datasets, not just the physical (path) information.
An example may help. I want to transmit an order for manufactured goods,
say an HPe3000. The order consists of a number of separate parts, which
have a hierarchical relationship to each other:
<order>
<heading> (exactly 1)
<sold to> (exactly 1)
<ship to> (exactly 1)
<address> (exactly 1)
etc.
<bill to> (exactly 1)
<address> (exactly 1)
<ship method> (exactly 1)
<notes>
<note line> (0 or more)
etc.
<line> (1 or more)
<item number> (exactly 1)
<part number> (exactly 1)
<description> (exactly 1)
<description line> (1 or more)
<unit price> (exactly 1)
<quantity> (exactly 1)
<option> (0 or more)
<option number> (exactly 1)
<description> (exactly 1)
<unit price> (exactly 1)
<quantity> (exactly 1)
<note> (0 or 1)
<note line> (1 or more)
<note> (0 or more)
This hierarchy can be represented in many different ways in a network
(IMAGE) data base. The header and lines are probably in separate
datasets. The bill-to and ship-to addresses may be in another dataset,
and the notes are probably in yet another dataset, as are the
descriptions. Parts and options may share the same dataset, with
applications understanding the difference by using some item in the
record. When the order needs to be transmitted to another organization
that's agreed to use a common XML DTD, an application program builds this
representation that shows the hierarchy explicitly.
The advantage to a properly-constructed XML application is that it allows
a program receiving the data to see the object hierarchy explicitly, or
to ignore it and concentrate on the items. This last is useful when I
have specific operations I want to perform on some objects without regard
to their place in the hierarchy. For example, I may feed all <address>
objects to a module that figures out the correct zip/postal code and
converts them to my standard internal format. When I do that, I don't
care what the address is; I just care that it's an address. An XML markup
makes that easy to do in an application-independent way.
>I do see uses for XML for data formats that change often, but having a
>fixed record layout (that very rarely changes) compiled into the
>programs
>seems easier for the programmer to understand, code, debug and faster to
>execute (the old flexibility vs. speed trade-off). The cpu cycles aren't
>free and I doubt that many shops have much excess time in the morning
>after the night's batch run.
Nobody, I hope, is seriously suggesting that XML be used instead of a
data base. Gavin is right in one thing, that XML (like Java, or ActiveX,
or structured programming, or (many years ago) Pascal) is being overhyped
and is presented by some as the answer to every problem (PL/1). XML is
great for exchanging data among loosely-coupled systems. But in trying to
come up with an XML interchange standard that solves practical problems
(see the previously-given link <http://www.rets-wg.org/docs/>, I've had
to fight off XML zealots who think that all databases should be turned
into zillion-level abstractions, and who prefer to deal with real data
and real people only as a last resort. I'm not one of the zealots, but I
do see XML's value for interchange applications.
The short way of stating the value of XML to traditional HP3000
applications is that XML is a standard for flattening data hierarchies
for purposes of exchange.
>I might have this all wrong but, are the XML tags embedded in each
>record? That is, does each record have to have it's tags parsed? If so,
>this seems rather redundant unless your appl calls for various record
>formats all intermixed (but I would still vote for a rec-type field
>instead for most appls).
The answer is yes, tags are embedded in every "record". But as the
example above shows, XML isn't about records, it's about objects and data
streams. The tags are necessary to show which part of the data stream
contains which parts of which objects. See
<http://www.rets-wg.org/docs/retsdtd.pdf> for a sample DTD and encoding.
>Erik (still not quite ready to run out and buy my first XML book)
>Vistica
When you are, you might try a book called _Just XML_, by John Simpson.
It's a bit outdated, since as of today it's almost 18 months old. But
it's a good answer to the question "Why (or rather, When) XML?"
-- Bruce
--------------------------------------------------------------------------
Bruce Toback Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc. (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my friends -
Phoenix AZ 85028 | It gives a lovely light.
btoback AT optc.com | -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.
|
