[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Fw: XLink: behavior must go!
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|