Re: Another try on groves
[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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format