Re: Friction and cross pollination

Robin Berjon <robin@berjon.com> writes:
> Here goes. As always: comments, tweaks, screams, etc. welcome!
>
> """
> This Task Force believes that while complete alignment between the
> HTML and XML families may not be achievable or indeed desirable there
> are nevertheless areas in which cross-pollination between those two
> stacks could help improve either or both. Now that the delineation of
> these techonologies' respective domains have stabilised it would be
> more foolish than ever that these communities behave as warring
> factions while closed, proprietary formats still abound. Despite the
> important design differences that exist between HTML and XML their
> goals are not as divided as our mailing lists suggest, and one can
> still share experience regarding the production of round wheels
> irrespective of the rail track gauge.

I'd wordsmith that a bit:

  This Task Force believes that while complete alignment between the
  HTML and XML families may not be achievable, there are nevertheless
  areas in which cross-pollination between those two stacks could help
  improve either or both. Despite the important design differences
  that exist between HTML and XML, their goals are not as divided as
  some of the stormier rhetoric suggests. There are plenty of areas of
  common experience despite significant differences in the details.

> A suggested list of such smaller projects, which may or may not
> proliferate best in a standards setting, could for instance include:
>
>     • Defining an XSLT and XQuery serialisation for polyglot HTML.
> Usage: make it trivial to produce it with a regular XML tool chain.
> [ed. I thought that this had been done, but I can't seem to find it
> anywhere]

[ It's on my plate, I think :-/ ]

>     • Help define an improved, more interoperable, and more usable
> version of DOM level 3 XPath for use from Javascript inside an HTML
> document. Usage: a number of queries (e.g. for text nodes, or certain
> axes) are impossible to achieve with the Selectors API, but using DOM
> level 3 XPath is unwieldy at best.
>
>     • CSS Fragment IDs based on XPointer as described in
> http://simonstl.com/articles/cssFragID.html. Usage: links that target
> fragments more powerfully, in a manner that browsers understand
> (http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/
> is a good example).
>
>     • A Javascript and/or CSS based transformation and templating
> language that would reuse the best of XSLT (notably its processing
> model) and apply equally to HTML or JSON. One potential starting point
> may be http://www.w3.org/TR/NOTE-STTS3. Usage: Javascript templating
> libraries are proliferating like rabbits but they tend to be limited
> to simple variable interpolation. Support for more powerful HTML
> production pipelines would benefit from a more powerful approach.
>
>     • [ed. please don't shoot me] Making sure that one can fully
> render XSL FO using nothing but Javascript and CSS, as done with
> pdf.js (http://andreasgal.com/2011/06/15/pdf-js/). Usage: FO is nicer
> to produce than PDF.
>
>     • Despite its name, EXI is a compression technology that is
> designed to apply to any tree. Investigating whether it can be applied
> to HTML or JSON could yield sizeable gains. Usage: performance is
> increasingly a concern in the HTML family. Enabling faster serving in
> general, and supporting lighter-weight devices without the need for an
> intermediate proprietary acceleration proxy would improve the
> ecosystem.
>
>     • Collaborating in the ongoing work on a Web component model to
> ensure that it applies across the board. Usage: open a door that
> actually works on distributed extensibility.

Some of these projects appeal to me more than others, but is there
a consensus on any (sub)set of them?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com