[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


iframe vml
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.