Re: Alternatives to browsers (was Re: Alternatives to the W3C)
Miles Sabin <msabin@c...> writes: > Didier PH Martin wrote, > > The important thing to see here, is that if we use a common > > format for either document or data, then data could be seen as a > > document. For instance, the marshaled content usually opaque can > > be seen as a document and displayed in a browser. Or a document > > could be transformed and fed to a CORBA/DCOM object. The end > > result versatility and a huge paradigm shift to do ;-) > > Remember that my original question was, 'Why is _application_ > specific_ markup preferable to an _application_specific_ binary > wire protocol'. One answer to your original question is precisely that, with markup, the data/document is free to evolve in non-application-specific directions. The web is perhaps the ultimate expression of this -- clients and servers have both proliferated, tied together only by a common protocol and markup language. Another is that data can be stored in a file or database as well as going over a wire. As soon as you add persistance to the mix, markup languages have a very clear advantage because it is much easier to change the internal data representation, and to add and remove fields to the data structures. As long as you have reasonable defaults you can continue to use, (or optionally upgrade) the old files. > XML encoding gets you a common generic format, but it doesn't > get you semantic transparency. So, sure, you'd be able to > parse the contents of XML rpc packets, but that doesn't mean > you'll be able to do anything interesting with them. "Semantic transparency" -- by which I assume you mean the ability to transport behavior as well as data -- is IMHO usually a bad thing: it severely limits your flexibility. Of course, you can still do it, even in XML: <define element="factorial"> <if><test-zero><get var="content"/></test-zero> <then>1</then> <else><factorial><subtract><get var="content"/> 1</subtract> </factorial> </else> </if> </define> but that doesn't mean it's usually a good idea. Usually it's better to put data and behavior (e.g. style; "business rules", ...) in separate documents. -- Stephen R. Savitzky <steve@r...> <http://rsv.ricoh.com/~steve/> Platform for Information Applications: <http://RiSource.org/PIA/> Chief Software Scientist, Ricoh Silicon Valley, Inc. Calif. Research Center voice: 650.496.5710 front desk: 650.496.5700 fax: 650.854.8740 home: <steve@t...> URL: http://theStarport.org/people/steve/ 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/ or CD-ROM/ISBN 981-02-3594-1 Unsubscribe by posting to majordom@i... the message unsubscribe xml-dev (or) unsubscribe xml-dev your-subscribed-email@your-subscribed-address Please note: New list subscriptions now closed in preparation for transfer to OASIS.
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