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