xml-dev - Re: Fw: XLink: behavior must go!

[Paul Prescod <paul@prescod.net>]

Oren Ben-Kiki wrote:
> 
> Note I'm not enthused by "javascript:behavior",
> since it is inconsistent with the XML-as-data-language view.

I am also not enthused by that idea. I am pandering^H^H^H^H^H^H^H^H
demonstrating that the stylesheet-centric idea is still compatible with an
ultimately flexible, inline behavioral definition. Whether that definition
is compatible with good design is another question.

> 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.

> 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.

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.

This means that the two can actually work together pretty nicely. The
light switch doesn't have to send an object to define its capabilities: it
can send a message. But it may be too complex to define the GUI for the
object completely declaratively (maybe XUL isn't enough) so you could send
some code instead.

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.

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.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Earth will soon support only survivor species -- dandelions, roaches, 
lizards, thistles, crows, rats. Not to mention 10 billion humans.
	- Planet of the Weeds, Harper's Magazine, October 1998

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)