xml-dev - About template. part 2

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

Hi,

As Isaac Asimov did for the robot world, let create some rules for the
semantic web.

The first phase of the Web saw the emergence of dynamically created HTML
pages. These pages are mostly constructed with template based tools (i.e.
Cold fusion, ASP, JSP, PHP, etc..). These template based tools include code
fragment or special elements to extract data from data sources. The role of
these code fragments is to convert data into rendition objects and more
particularly into HTML objects. The result of such process is a HTML
document ready for rendition by any HTML aware browser (more or less).

Rule 1:
-------
The semantic web will be based mostly on templates. These templates won't
produce presentation document (i.e. HTML) but model document (i.e. XML).
After being created or fetched from the server, the model document is then
sent to browsers. These latter, do the transformation from the model to the
presentation. Thus, contrary to the phase one web, template based tools will
be used to create the model on the server and the browser will convert it
into presentation.


Note:
----
 During the phase one web, the server sends one document to be interpreted.
The HTML document. During the phase two web, at least two documents are sent
to the browser: a) the model, b) the "render" method which takes the form of
a style sheet. We then have now an "object" containing data and a "render"
method. Later on, more methods may be added.

To be more precise, the two documents (i.e the model and the style sheet)
may not be physically separated but included into a single physical
document. However, it remains that the model is separated from the
presentation and more than one method can potentially be applied to the same
data on the client side. for instance, an E-check could be displayed in a
browser (the "render" method") and also posted to a local accounts
receivable module (the "post to accounts receivable" method).

Of course the image of a browser, present in our mind, is that of today's
browsers. But we can, as well, envision a "workflow" folder receiving the
document and this latter appearing as a file icon. A mouse click on the
document's icon may reveal all available methods like "render", "post to
accounts receivable", etc.. The code for these methods may come from the
net, be locally resident and matched to the document as long as a possible
matching could be made locally. Thus, the final object could be the assembly
of code locally or remotely resident. The methods assembly is based on a
match between the document and the local methods or accompanying the model
as sent by the provider.

Is this what we call a paradigm shift?

Hence, we'll move from:

     server					 Browser
template + data = HTML -----------> render HTML

to:

     server					       browser
template + data = XML -----------> XML+CSS or XML+XSL or xml+??

rule 2:
-------
The structure of the model is not known "a priori". The model document is
assembled from a collection of fragments. The final XML document is more an
aggregate than a document conforming to a fixed structure.

rule 3:
-------
During the aggregation process, the document "in progress" may not be
serialized as a text document but may take more the form of a hierarchical
structure manipulated through an API. The output sent to the browser,
though, will be serialized for the exchange process. The server role is then
a role of creating an XML document and the role of the browser to provide an
interpretation on this document. The most common interpretation being the
rendition for human consumption (i.e. get access to the information through
our senses).

Problems to resolve:
--------------------
Provide to the client solid pattern match tools so that local methods could
be matched to a particular data. This process is called "object assembly".
The object being finally assembled on the client side not solely on the
server side. Let's take again the example of the E-Check received in a
"workflow" folder. The rendition can be provided by the sender so that the
check appear on the user agent as the sender want it to appear (for brand
recognition and re-enforcement). The "post to accounts receivable" cannot be
coming from the sender and has to be provided locally. To do so, the local
agent has to be able to match the incoming model and the "post to accounts
receivable" methods available only on the local station. Hence the final
object assembled on the client side has one method provided by the sender
and one locally matched to the model. The local client sees an object with
these two methods: "render", "post to accounts receivable".

Possible issues I envision:
---------------------------
When part of a workflow, a model may vary in time. Thus, new fragments may
be added, actual fragments deleted or transformed. Thus, our notion of XML
documents as a static entity may be seriously handicapped when confronted to
a "data flow process" (for computer scientists) or a business or workflow
process (for business scientists). Can we envision an XML document with a
structure varying in time? We may have to if we want to create "data flow"
systems to model business processes (i.e. workflows).

Dreams are simply potential realities
unknown author.

Didier PH Martin
mailto:martind@netfolder.com
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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe 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)