Another try on groves

[Sean Mc Grath]

[Paul Prescod]
[...]
> A frame is not an "element", it has no
>"attributes". Now I claim that a frame is an object and that it has
>properties. And any idiot knows that objects can be represented in XML
>using a variety of techniques but think about the logic of doing it this
>way: you are taking a thing that is "logically" an object, expressing it
>in terms of a text file format so that another module in the same
>process can re-interpret it as logical objects.
>
>The *only good reason* to dumb something down into XML elements and
>attributes is to move the information between processes separated by
>space, time or incompatibility.

I believe it makes perfect sense to *think* of MPEGS, PDFs,
whatever, in XML terms.

I't does not of course, make sense to *store* them as XML owing
to the enormous size bloat. But who said the XML needs to
physically exist in disk?

Case in point, I have written a SAX driver for the MySQL
relational database. I have SAX software that can happily
trundling through 1GB of records treating them as XML. The
XML never physically exists but the entire API used to
process the MySQL is SAX.

I can get programmers who have never seen MySQL, or its
API, to write MySQL processing apps using a purely
XML API. I do not see why the same cannot apply to
other formats such as graphics, sound etc. In fact,
I am working on a BMP driver right now.

> Using XML as the "universal API" is
>madness because there *is no universal API*.

I have shown above how a non-XML source (MySQL)
can be programmed with an XML API using SAX. I see
no reason why a virtual DOM could not be implemented as well.

I do not see what XML cannot be a universal API.
Reasoning that it cannot because of size restrictions
does not hold water because there is nothing stopping
an XML document being as virtual as you want it
to be. The virtual-ness of an XML document does not
stop you programming it with an XML API.

> The idea is patently
>ridiculous. (some Unix evangelists have claimed that open/read/write is
>hte universal interface but actual Unix usage demonstrates that this is
>not even close to true...look at the heavy usage of CORBA and IDL in
>Unix GUIs)

The Unix evangelists played with the idea that the concept of
*lines* of data, flowing through pipes, was the universal API.
I believe they were on the right track, but placed
too much emphasis on the concept of a "line". Joining
line-aware utilities into pipes worked brilliantly well -- for
data that fits simply into a line-oriented structure.

Things start to get bent out of shape when the data that
needs to flow between apps is hierarchical...

I believe it was the need to shunt hierarchical data around
that caused the shift to data-specific APIs. I remember writing
a C program on a Sun workstation many years ago to dump out
information about the last time a particular user had logged
on. I cannot remember what the file was called or what
the record structure was, but I do remember being suprised
that it was a lump of binary data and required its own
API. This seems very un-Unix like to me.

I do not think it is necessary to bend things out of shape
now that XML is reaching meme status. A whole new vista of
possibilities open up if you change the concept of a Unix
"pipe" from a line-oriented data flow, to an XML-oriented data
flow. Hierarchical data could then flow through pipes just
as easily as flat data. Flat data would simply be the
degenerate case of a hierarchy of depth 1. All the
advantages of pipes in terms of blocking buffers,
virtual data streams and so on remain!

I see no reason why GUI data, user logging info, whatever,
cannot be programmed with an XML API. Going the other
way towards data-specific APIs is, for me, the bad
old days of proprietary data formats, steep learning
curves and low programmer productivity.

I would love to see a Unix that could flow XML node, by node
through a pipe. Just thinking about what you could do with
it turns me into a giggling wreck:=)

regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</Sean>



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)