[
Lists Home |
Date Index |
Thread Index
]
David Carlisle wrote:
>>It doesn't need to scale to more than the number of languages that have
>>their own specific rendering needs that can't be expressed on top of
>>another language.
>
> yes and no, you can rely on a transformation language xslt (or xbl about
> which I know less) for rendering but the more you transform, the harder
> time you have with any interaction as you have to do the reverse
> transform (typically) to map user interaction with the layout pimitives
> back to your underlying elements.
Exactly! And that's precisely the problem space that XBL wishes to
address. It performs simple transformation (simpler than XSLT) but its
main value is in providing the wiring to manage interaction between the
source tree (which remains as is in your document) and the rendering tree.
XBL is currently a Mozilla thing, but a subset for SVG is on Rec-track:
http://www.w3.org/TR/sXBL/
It is expected that sXBL will soon enough be followed by a v2 that will
be more generic and closer to XBL. In the meantime, XBL is very much
usable even if not standardized. WGs outside SVG and CSS have already
expressed interest, the MathML IG should probably take a look.
> The amount of transformation that you are prepared to accept as
> reaonable is of course subjective. So opinions will differ as to whether
> such a solution is acceptable. Is it OK to map ChemML (or MathML) to SVG
> for example, given that SVG can lay text at specific coordinates pretty
> much any layout form could in principle be rendered that way but you
> might (or might not) lose something along the way.
The whole point is that your source DOM stays remains your source DOM,
period. What sXBL does (in a nutshell) is that it decorates that with
"shadow trees" that are what gets rendered.
> David
> (I suppose I should declare an interest:
> Co Chair W3C Math Interest Group)
(of relation to this discusion: member of SVG WG, CDF WG, and the
Binding TF which caters to sXBL)
--
Robin Berjon
|
