[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
Great explain: one question> Instead of installing to the browswer (or changing the client side settings), maybe test the browser interpreter for variance to expected [desired behavior] and let the server repurpose the "information content unit [ICU]" before performing the download put? This would require download a "test info unit [TIU]" to the client, allow browser natively to process the "TIU", capture the TIU output, backload the TIU output to the server, check the TIU output, repurpose the ICU according , and download the "[ICU] to the client side browser? just a thought On Mon, 24 Jul 2006, Didier PH Martin wrote: > 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 > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> >
|
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
|