[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: [SUMMARY #1] Why is there little usage of XML on the'vi
Hello Peter, Here are, to my knowledge the different strategies I found during my experiment in Didier's labs. a) Increase the adaptive power of information units with declarative code. Usually, the declarative code based on XML or SGML need an interpreter to know what to do with it (render it, process it, store it). If the host environment is variable and unpredictable because of user settings or versions limitations then the imperative code can act as a buffer to help adapt the information unit to the target environment. Most of the failures are caused by this lack of adaptation strategy. On desktops, this task is handled by install programs, It is dummy to think that putting a program on the desktop is sufficient to run it, some settings and pre-requisite checking is necessary for adaptation. The trouble was that, the community though that the declarative code interpreter (i.e. the browsers) were sufficient for the task. After 10 years of direct contact with the beast we can say it's a wrong assumption. b) Think of browsers as interpreters able to interpret declarative languages (HTML) and imperative languages (javascript). If we focus too much on the information unit and its incarnated document, we may forget that once loaded into a browser they are interpreted into different object. For example, HTML elements are translated into visual objects. A <div> or a <p> is translated into a block area. Therefore when loaded into a browser they are no longer a <div> or a <p> but more a block area with all its implicit or explicit rules and behaviours. c) There are no such things in the physical world as a standard. We have only interpretation-implementation of it. As soon as we accept that browsers are different because development teams have different interest and because none of them want to be commoditized, we will search for an adaptation strategy. The key word here is ADAPTATION. After 10 years we have sufficient proof that there is no such thing as a standardized environment, maybe one day before I die but not after 10 year of web technologies development. Practical strategies I used in browsers: I use a lot XML and XSLT because I came to master what "model driven" development means. I create a data model encoded into XML then transform it into a visual model using one of the rendering languages I get on hand (HTML, VML, SVG, SMIL, etc...) I tend to see XSLT templates as constructors. For example, An RDF or PDML documents are translated into the same visual structure incarnated by a hierarchy of <div> to build a treeView. This way I can RE-USE the same javascript behaviours. I created an engine to wrap the transformation engines on two platforms IE and Mozilla. The latter also perform other adaptation tasks. The result of a transform + javascript code can be invoked as: A URL (calling the interpreter like a function call and passing the set of parameters) As <frame> <iframe> attributes. In this case the parameters are passed as attributes and the source contained in the frame/iframe is again the interpreter. Up to now, two ways to pass parameters to the engine: trough a URL and as attributes: a REST way and a declarative way. What I am adding now is with a javascript call as the JMOL team is doing. Hence an imperative way to invoke the engine and pass parameters. Up to now I focused on different ways to invoke a client engine but based on the recent comments still need to add more code for platform checking and adaptation strategies to different capabilities. You can notice though that all strategies need the help of javascript code to set the proper environment. I soon discovered that relying solely to declarative code and its related meaning for different browser is doomed to failure. We need a buffer between the environment variations, this is like mitigating risk. Most information unit publishers are publishing at risk. Like in the finance world we probably need an index of the publication at risk. If we rely too much on browser developers for that, is like being dependent on big brother to make a good living. Therefore, actually, for everything out of the browser box and therefore everything outside of the basic HTML interpretation, we need to provide some adaptation code because outside of the HTML box, the information unit is at risk of not being well interpreted. Try to explain to your dog the string theory (I would not even try with my neighbour :-) So why do we think that the browser would interpret properly any out of the box language. Just to recall, for browsers at large anything outside of HTML is something out of the box. We say that a good question leads to good theory. Then, when we publish an information unit we should ask. How this will be interpreted in different platforms. What kind of settings the users will set (set javascript interpretation to no, not having the right VM, etc...) The answer desktop developer got to this question was: let's create an install program. There are no differences in the browsers world. To reduce maladaptation, you need an installation program. Cheers Didier PH Martin http://didier-martin.com
|
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
|