xml-dev - About xlink tools

["Didier PH Martin" <martind@netfolder.com>]

Hi Peter,

With my experiments in Didier's lab I found that if the browser support
scripting, the DOM and XSLT styling, then you have the ingredients to create
your own Xlink interpreter. For instance, an xlink:extended element can be
converted into:

a) a portal widget.
b) a context menu that appears when the user click on the link object.
c) an index table as found in books.

In fact, with these experiments, and I already posted a link to one of
these, I will post links to other ways to process an xlink:extended element.

The main point here is that, with XML+DOM+script+XSLT you have, in a certain
way, browsers that process data models, the behavior can be provided by the
author. The more I play with this, the more I think that what are in face of
is a new breed of language environement and that this environement is
closely related to environements like VB or Delphi. I'll explain what I mean
here:

a) The model or data is provided in the form of an XML document. For
programs like VB or Delphi the data is coming from a data source. Thus for a
browser aplication the data source is the XML document.
b) The model is transformed into HTML+script+DOM. Here, the best analogy
that I can find is that an HTML document that includes scripts are like
Delphi or VB programs. You have on one side a hierarchy of objects that are
laid on a scrollable surface. These objects, when hit by a user action
(through the mouse) emit events, these events are processed by event
handlers. Visual basic source document are structured in ways such as the
object hierarchy and their relative properties are first listed, then the
functions or event handlers and their content are following. We have now
such a structure with HTML where the objects are the HTML object. Each
object has its own property set, its own set of events. Scripts can contains
event handlers, functions and procedures. So, we have basically the same
structure as a visual basic form but instead of VB you have EcmaScript.
Interesting to note that few saw the resemblance. I encourage you to look at
an HTML document containing scripts and to look at a visual basic ".frm"
file (a text file), you'll be surprise how close these two structure are.
Hence, the XML document + XSLT can produce a program like vb. If it is a
program that I created, it can interpret the model in the way the program
creator though of.
c) the program created with XSLT is an interpreter. We created a layer
between the model (the XML document) and the user. We created a program that
can interpret the model in different ways .

So, what I discovered at Didier's lab is that using XSLT I did more than
simply creating style to the XML document. I was also able to create a
program, a way to interpret the XML document. If the XML document contains
links, I can therefore provide ways to interpret Xlinks. It means that the
browser does not need to include all possible behaviors. It means that the
browser is more a run time interpreter with a certain library of layout
objects already installed. It also means that a browser is more a framework
or a run time interpreter than an application.

So, last week, I listened to the thread about the browsers with interest and
saw that some see a browser as a kind of electronic book or electronic
document reader. For them the browser just render documents. For the others,
it is a run time, a library of layout object and a language to compose an
application.

Moreover, when an XML document contains a PI that links this latter to a
style sheet. We potentially created here an object. This object is composed
of data (the XML document) and behavior ( the HTML+Script created by the
XSLT transformation sheet). What is different from other object based
environments is that the program is composed at the last minute by XLST.
Thus, the program is composed on the basis of the model and if the model is
different or that it omit or add information elements, the resultant program
is different.

Nikita, last summer at XMLdev99 in Montreal, showed us that indeed with XML
+ XSLT we have now the possibilities to create a new bread of applications.

So, the paradigm that I am proposing here is that if an XML document
includes an XSLT transformation sheet that creates an HTML+Script entity, we
have created an object with a just in time mechanism. The just in time
mechanism compose the object base on the model. This different data model
leads to different objects. The resultant object is therefor not static and
creted once and for all but more an entity created on the type and structure
of data. Contrary to object oriented environments where the object is
static, in this case, the object is constructed on the basis on the model
(i.e the data, the XML document). As such the resultant object, provides an
interpretation to the model (i.e. the data). So, if the model includes an
XLink model, then the application can provide a particular interpretation to
some xlink entities. There is potentially as many xlink interpretation as
there is application created as mentionned earlier. For instance, the object
creator mya decide to use the list and anchor object from the HTML object
library. Each object has a certain behavior and has a certain set of events.
We can either keep the default behavior or overload the exiting one for our
particular xlink application.

In fact, we could as well create editors with this technique but political
issues prevent us to do so. To remove some of these political barriers, we
can hope that the Mozilla project will have more resources so that at least
a Mozilla release can happen this year. Meanwhile, for those having no
political agenda and just a desire to experiment or develop real life XML
apps, we unfortunately have only one choice.
If only the SUN, the IBM, the Oracle and the AOL of this world would simply
walk their talk....OK Didier, stop dreaming, this is not their goal. Their
goal is to knock their main competitor and make sales, not resolve our
problem (unless there is some money to make :-)


cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com


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/ or CD-ROM/ISBN 981-02-3594-1
Unsubscribe by posting to majordom@ic.ac.uk the message
unsubscribe xml-dev  (or)
unsubscribe xml-dev your-subscribed-email@your-subscribed-address

Please note: New list subscriptions now closed in preparation for transfer to OASIS.