- From: Liam R. E. Quin <liam@w3.org>
- Date: Sat, 28 Mar 2015 00:27:50 -0400
- To: Miles Fidelman <mfidelman@meetinghouse.net>
- Cc: public-html@w3.org
On Fri, 2015-03-27 at 16:04 -0400, Miles Fidelman wrote:
> I'm amazed that nobody has yet commented on the implicit
> premise, which I read as:
>
> - JavaScript is a processing pig
> - with the addition of a few, well-defined constructs to HTML, with
> support from browsers, we could do a lot of what we want (or what
> people
> are doing) - without the overhead imposed by JavaScript
>
> To me, this seems like a very good thing.
I'm not sure it's entirely true and, even if it is, I'm not sure if it
matters as much as we might think, even those of us who started out
with PDP11 assembler.
> It seems like:
>
> - It's getting harder and harder to do simple things. Too many
> JavaScript frameworks and libraries. Too much complexity. Authoring
> should not require extensive programming skills. (Whatever happened
> to the read/write web?).
The frameworks make mindblowingly complex things possible or even
easy. I don't think they make anything harder, unless it's choosing a
framework.
The read/write Web is not related to this at all.
[...]
> As to the specifics, it sounds like the proposal is to move some XML
> processing functions into the browser. To me, Xpath, XSLT and
> XQuery, maybe a basic XML database - all in a browser, instead of
> server-side - sounds like a viable alternative to JavaScript for a
> lot of applications. Implement first as a JavaScript library, as a
> test and transition path. Could be kind of cool. Might also end up
> being just as much of a processing pig as JavaScript.
XPath and XSLT are already in Web browsers, albeit very, very old
versions of XPath and XSLT.
There have been interesting experiments with e.g. SaxonCE and
frameless.io in having a more recent XPath and XSLT in Web browsers,
and I know people have embedded XQuery in browsers with plugins.
We (the XML community, if there's such a single thing) did a really
bad job of selling XML to the Web community. Partly it was because, at
the time, the people working on XML were professionals in information
design, and from that perspective HTML was like one more word
processing format - not what you want to use for your domain-specific
information but a possible output format, and not very interesting.
In the meantime lots of people took XML and ran with it in other
directions, some good and some really bad, and even at W3C it seems (I
wasn't working at W3C at the time) people had weird ideas like "XML is
intended to replace HTML" that were both incorrect and confrontational.
Ideas such as separating script and content ("unobtrusive"),
separating style and content, declarative languages, were all part of
XML and SGML and inherited (in theory) by HTML from SGML. These ideas
have been slow to take hold on the Web, in general, but are pretty
firmly there now. We're seeing a resurgence in domain-specific
languages and various functional and declarative languages are coming
out of that, too.
Although I certainly have use for XSLT and XQuery in Web browsers the
languages weren't designed with that in mind. XSLT is actually fairly
widely used on the Web today, and XPath even more so. You can also
find people (and organizations) using the model-view-controller design
pattern with XForms in the browser. It would be interesting to develop
something XProc-like to be reactive to client events -- XProc is
essentially a declarative dataflow language. But the right answer here
is to develop something and show people it works.
Liam
W3C XML Activity Lead
>
> Miles Fidelman
>
>
Received on Saturday, 28 March 2015 04:27:58 UTC