About template. part 2
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@n... http://www.netfolder.com 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 unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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