Alternatives to browsers (was Re: Alternatives to the W3C)

[Stephen R. Savitzky]

Miles Sabin <msabin at cromwellmedia.co.uk> 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 at rsv.ricoh.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 at theStarport.org> URL: http://theStarport.org/people/steve/

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/ or CD-ROM/ISBN 981-02-3594-1
Unsubscribe by posting to majordom at ic.ac.uk the message
unsubscribe xml-dev  (or)
unsubscribe xml-dev your-subscribed-email at your-subscribed-address

Please note: New list subscriptions now closed in preparation for transfer to OASIS.