XLink: behavior must go!

[Oren Ben-Kiki]

Paul Prescod <paul at prescod.net> wrote:

>I wrote:
>> The way I see it, the code vs. data debate hasn't been settled yet. The
>> current accepted technology, HTML, is a hybrid of both and therefore
nobody
>> likes it. XML is on the pure data side, but its success is yet to be
seen.
>> Java is on the code's side, and its success is also not clear (the Jini
>> project, for example, demonstrates what this approach can achieve if
>> seriously adopted).
>
>Could you outline what you consider to be the successes of Jini? The idea
>of my light switch communicating with my refrigerator via migrating Java
>objects strikes me as kewl but highly brittle. The declarative part of an
>API specification leaves so much unsaid. I would feel much more
>comfortable if I heard that Jini was a set of APIs *and* data formats.


I didn't say Jini had any successes yet :-) As to the potential, I'm less
interested in the lightswitch talking to my refrigirator, as cool as that
sounds. What I see in Jini is in the short term a way for practical zero
(well, epsilon) administration for SOHO, and a way to do really neat things
for mobile computing. In the long term, I simply love the idea of replacing
the PCI bus with a 1000 ethernet micro hub. Instead of having a fat ugly box
it is a hassle to upgrade, you have a small pile of cubes plugging into the
network, which you can upgrade individually, just by plugging one out and
plugging a new one in. USB and FireWire give some of this to an individual
user; Jini can give it to a whole net.

>> The ultimate test of both approaches is trying to use a document/object
in a
>> system it wasn't designed for.
>>
>>...
>>
>> The code approach is less suitable for adapting to unexpected
applications.
>
>Hey, doesn't that mean "we win?" According to you the migrating objects
>mechanism is "almost" as good as migrating data but "almost" only counts
>in horseshoes and hand grenades.


The code approach has one thing going for it - power. Consider an HTML page
with embedded JavaScript. There's simply no way the same effect can be
achieved with a pure data approach. We'll always have some of both.

>Seriously:
>
>One virtue of migrating objects is that you can build data-based solutions
>on top of them. You just tell your migrant objects to stay put and send
>messages instead.


You could make the reverse case - allow for migrating objects but wrap their
API in terms of something like XML. Both approaches aren't exactly elegant.


>My problem is that most people don't understand that there is a spectrum
>and a conflict here. So they often go straight for the programmatic
>solution without verifying that a declarative solution is impossible. They
>sense that the programmatic solution is more powerful but don't recognize
>the long-term costs (a perfect example: the recent (informal) <xml:script>
>proposal). This leads to abominations such as Postscript, Display
>Postscript, .bashrc's etc.


First, it typically takes several years of experience with a programmatic
approach before a good declerative approach can be formulated. The move from
one to another is a sign of the maturity of the system. In fact you can view
this in the evolution of programming languages themselves; much that was
"programmatric" in older generations is "declerative" in newer ones.

This shouldn't lead us into the trap of assuming that anything at all can be
done "decleratively". A complex "declerative" language is worse then a
simple "programmatic" one. For example, if printers used Prolog instead of
PostScript (never mind the obvious inefficiencies), would that have made
things better in any way? Hardly.

As usual in these type of issues, what we'll see in the end is some sort of
a hybrid system.

<DayDreaming>
Imagine an object oriented architecture with a clear seperation of data and
code; data is specified in XML and code in Java or JavaScript, accessing the
data via a DOM interface. The difference between it and HTML + JavaScript or
simple migrating Java objects would be that the relationship between the
code and the data would be much more clearly defined.

Assuming that small issues of security, standard interfaces, standard and
per-application libraries, version control, distribution etc. are resolved,
such an architecture has the potential of being the ultimate "it". For
example it could do anything Jini does, probably better. The role of the
operating system would be reduced to offering the standard library. Network
protocols would be reduced to a single one passing this sort of object.
</DayDreaming>

>The Unix community in particular is going to have to come to grips with
>the idea that more powerful is not necessarily the same as better.


Funny you should say that. UNIX has started with "almost everything is a
file" approach and got pretty good results. Plan9 took it on to "really
everything is a file" and got better results (technically). What I suggest
above is similar in spirit to what may be called a PlanX approach -
"everything is an XML document" - where the additional twist is "with some
code attached", and "with a clear relationship between code and data". I
don't see this as being against the UNIX spirit at all. Rather I see it as a
natural evolution of its concepts.

Not that I expect anything so clean and elegant to emerge from what humanity
employs as a development process for its technology :-)

Share & Enjoy,

    Oren Ben-Kiki


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/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)