Actually, one of the facets I've always found fascinating is that most of the @type attributes tend to be overwhelmingly dominated by a single language. In theory, there's nothing wrong with saying
<?xml-stylesheet type="text/javascript" href=""myTransform.js"?>
<script type="text/xquery"/>
<style type="application/xslt+xml">
etc., but in practice, of course, such extensibility is so foreign to most web browsers that I suspect most browsers don't actually even have stub code for any alternatives (and please don't ding me on wrong mimetypes here, just trying to get the idea across).
XQuery actually works surprisingly well in a script context (take a look at XQIB as at least partial verification of this -
http://www.xqib.org) but because there is no modularization of the scripting engine in a browser, it will always remain a very secondary technology except for the few XQuery geeks out there. There is a move to create XQIB using Javascript as the foundational language, and I suspect that this very well may be the only real route for such support moving forward.
Perhaps this is one of those areas that the W3C should push back on to the HTML5 group (which is largely synonymous with the vendors) - providing a way to extend the HTML5 model to better support modularization of functional capabilities, even if only through a consistent Javascript bridge (in the same way that you can use Java or C# as the VM for Python, Ruby or Perl.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project
On Thu, Dec 2, 2010 at 7:08 PM, Doug
<doug.duboulay@gmail.com> wrote:
On Fri, 3 Dec 2010, Ben Trafford wrote:
> On Thu, 2010-12-02 at 10:31 -0500, Simon St.Laurent wrote:
> > On 12/2/10 10:20 AM, David Lee wrote:
> > > I'll bite on this ...
> > > Conceptually, what is the difference between this suggestion (better
> > > CSS) then supporting XSLT in the browser ?
> >
> > Heh. I'm not sure the conceptual differences matter as much as reusing
> > technology that's already widely implemented in browsers.
>
> Precisely. The point is to enable XML with existing and well-understood
> technologies, to gain penetration with the widest audience possible and
> allow for the re-use of broadly understood technologies. XSLT is
> impenetrable to the average web developer.
>
> --->Ben
Yeah, off-topic I know, but just throwing this out there,
something, presumably trivial ...
I would like to see web browser support analogous to the
leading stylesheet processing instruction, but for processing with
javascript (which *all* web developers understand!).
i.e. instead of:
<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href=""convertXML2HTML.xsl"" type="text/xsl"?>
...
why not promulgate:
<?xml-javascript href=""convertXML2HTML.js"" type="text/javascript"?>
With this you could publish raw XML documents on the web and transform
them dynamically, client-side with javascript.
As a work around, for firefox, its currently possible to add an html
namespace <html:script /> element as the penultimate node and
coax it to process the preceeding XML content however you like
(at cost of invalidating your XML document of course).
Unfortunately IE treats all XML as an "XML Data Island" - a flat
list of unstructured opening and closing tags that need to be
re-assembled into a DOM tree in order to do anything useful,
including any embedded <html:script /> elements it contains :-/
A universally recognised javascript processing instruction could be
a useful addition to the toolbox.
cheers
Doug
[
Date Prev]
| [
Thread Prev]
| [
Thread Next]
| [
Date Next]
--
[
Date Index]
| [
Thread Index]
