[
Lists Home |
Date Index |
Thread Index
]
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>
>
|
