[
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
badly:
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:
<NumberList>
<Num>1</Num>
<Num>2</Num>
<Num>3</Num>
</NumberList>
...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
server.
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 :-)
ABS
--
A city is like a large, complex, rabbit
- ARP
|
