[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin said:
> 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.
>
Units can be reused and combined. In fact, part of the main problem with
XML is that cannot combine previous information units.
Take like examples the original grocery example either you chose a XML way
<grocery-list> or a HTML <ul> to markup; therefore you obtain or an
accurate markup is not understood online (the visible web) or a generic
markup with losing of information.
Browsers developers cannot implement basically the same stuff again and
again for the 600 different markup language based in XML known, more the
new stuff is becoming from the non-XML word such as next HTML5.
The idea is that if <ul> is already here, reuse it! instead duplicating it
from zero with <grocery-list>. Reusing is one of the reasons i invented
(at my best current knowledge nobody did before) the concept of
multimarkup. The idea is that i can complement <ul> with <grocery>
generating a composed tag <<ul><grocery>>. In that case only the grocery
part may be implemented whereas reusing the <ul> already available.
Of course, <<ul><grocery>> cannot be done in XML because its
hierachic-oriented markup, but i can be done in alternative approaches For
instance in CanonML.
[::ul content-here]
[::ul::grocery content-here]
Of course, you can define your own tag if desire (e.g. ::grocery-list) but
its semantics would be based in already available one, i.e.
::grocery-list ==> ::ul::grocery
Moreover, if by some reason the ::grocery tag is not implemented in your
browser it would be ignored but still the browser could access to the ul
part and understand at least part of your datument. With XML either your
software understand <grocery-list> or not. It is a kind of binary.
Yes XML has no concept of multimarkup, but XML people would search a way
to _simulate_ this so much as posible since i think it will become a
fundamental feature when markup languages explosion (i believe that
current 600 XML languages are just the begining).
> 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.
I do not understand you. Yes visually both <p> and <div> are not
differentiable (unless specific styles), but the DOM tree is able to
differentiate both. You can in source-view that both are retained when the
page loaded.
> 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...)
Yes, but one is forced to use the available constructs and cannot be
combined and extended. By combined i do not mean a mized datument with
XHTML as host language and MathML and SVH islands in different namespaces
but i explained above with multimarkup and reuse. By extension i mean that
one of ironies of the eXtensible language per excellence today (XML) is
being it does not adressed the extensibility at the client side, only at
the author side. I can extend SVH or HTML inventing new tags but none
browser will understand them. I do not think that was a problem of the
browser community, i think it is one of main design errors of XML.
> 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 like more a XSLT-JS-like approach rather than a Java-plugin or a
X3D-like (semantic layers over a basic 3D XML host language) approach.
Both the Java-plugin and the X3D-like approach may be suitable for
addition of small extensions or semantic layers) over a common basis. In
fact i think that main interest of the CML comunity (I wait prof.
Murray-Rust can correct me if wrong) is in adding the need
funcionality/extensions for the processing of CML units encoded on a host
language, probably XHTML based.
> 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.
Interesting! Do you mean some kind of automatic quality-check of the
client browser or what? Someting like the common bottom line in many
sites: this site is better display with ... you need JS enabled ... but in
the heading of the doc.
> Didier PH Martin
> http://didier-martin.com
Juan R.
Center for CANONICAL |SCIENCE)
|
