OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML as "passive data" (Re: [xml-dev] The Browser Wars are

[ Lists Home | Date Index | Thread Index ]

On Tuesday 22 October 2002 17:43, Mike Champion wrote:
> 10/22/2002 12:00:27 PM, Paul Prescod <paul@prescod.net> wrote:
> >Completely passive *is the whole point of XML*. XML is a _reaction
> >against_ active data. If you don't "get" why that's valuable then fine,
> >you don't get it. But it isn't like the inventors of XML had never heard
> >of objects. Many were object programmers.
> I think that's an extremely important point that doesn't get much
> emphasis.  There seems to be a presupposition that OO approaches to XML app
> design are de rigeur .... but the whole point of XML is to break the
> encapsulation of data!  Am I missing something here?

I think that's the whole problem with XML, though :-)

Nobody's yet given a good reason why data encapsulation is bad.

Some people have spoken out about problems with things that 'hide' your data 
away from you, but that's not the point - sure you encapsulate some data 

class Foo {
	String a;
	int b;

	Foo (String _a, int _b)
	a = _a;
	b = _b;

	// No other way of getting a and b out!
	public String toString ()
	return a + ":" + b;

But what data encapsulation is good for is abstraction:

interface NumberSource {
	public int getNumber ()
	throws NoMoreNumbersException;

class NumberList implements NumberSource {
	int[] numbers;
	int pos;

	...a trivial constructor...

	public int getNumber ()
	throws NoMoreNumbersException
		if (pos > numbers.length) throw NoMoreNumbersException ();
		return numbers[pos++];

class RandomNumbers implements NumberSource {
	Random r = new Random ();
	public int getNumber ()
	throws NoMoreNumbersException
		return r.nextInt ();

class Sequence implements NumberSource {
	int nextNum = 0;
	public int getNumber ()
	throws NoMoreNumbersException
		return nextNum++;

...now, with XML, if we defined that some web service returns a NumberList 
document like so:


...the web service could use any of the above algorithms to generate those 
numbers - HOWEVER some of them generate an infinite list of numbers, so the 
document would have to be streamed and processed with SAX (or equivelant) at 
the client to make sense of it.

So XML *doesn't* really break away from data encapsulation, it's just too low 
level to be involved with it. XML documents are like the lists of arguments 
passed to methods; Web services are more like *objects*.

The problem might be that there isn't real scope for polymorphism in XML 
documents; it would be nice if the random number web service could just 
return an XML document that could be accessed exactly as a NumberList 
document above, but didn't have to have all the number generation on the 

One potential solution is to define something like Postscript; rather than 
sending a serialised DOM tree you send a program in some scripting language 
that the client executes to produce a DOM tree. With lazy evaluation it 
needn't build the entire DOM tree in memory; the <NumberList> element node 
might just create virtual children on demand without keeping an infinite list 
of random numbers.

Postscript, for those not in the know, is actually a full-featured 
programming language; when a Postscript file is 'executed' it calls graphics 
primitives to lay the page out. You can get really tiny Postscript files that 
use fractal algorithms to produce immensely detailed hi-rez images :-)


A city is like a large, complex, rabbit
 - ARP


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS