Lists Home |
Date Index |
- From: firstname.lastname@example.org (Stephen R. Savitzky)
- To: email@example.com
- Date: 20 Jan 2000 14:00:06 -0800
Miles Sabin <firstname.lastname@example.org> 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
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
<else><factorial><subtract><get var="content"/> 1</subtract>
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 <email@example.com> <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@theStarport.org> URL: http://theStarport.org/people/steve/
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Unsubscribe by posting to email@example.com 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.