[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT vs Web Components

Subject: Re: [xsl] XSLT vs Web Components
From: "James Fuller james.fuller.2007@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 11 Sep 2014 15:25:32 -0000

FWIW- I can see building web components using something like saxon-ce ... I
don't see a 'versus' type argument here, they are complimentary
technologies where one is concerned with distribution, ease of authoring
and sharing and the other about solving problems with code (and working
with markup).


is a neat illustration of the kind of relationship between the X
technologies and web components ... to me I see web components as a
potentially useful bridge to getting markup into the browser again.

my 2 cz, Jim Fuller

On Thu, Sep 11, 2014 at 5:20 PM, Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Well, the vast majority of XSLT use is server side, and web components
> aren't likely to affect that directly. It's true that a lot of people are
> moving towards maintaining content in HTML5 as their master format,
> replacing things like Docbook and DITA, but it's a mistake to think that
> eliminates the need for transformation: it just becomes a transformation
> from one HTML5 document to another, in place of a transformation from (say)
> DocBook to HTML5.
> In addition half of all XML and all XSLT is processing data, things like
> financial transactions, rather than web pages. That's under threat in the
> long term from JSON perhaps, but not from web components.
> It's not clear whether you are talking about the future of client-side
> XSLT, or of XSLT generally.
> I would like to think that the only thing that will lead to XSLT's decline
> is when someone invents something better, and there's no sign of that on
> the horizon. This might be wishful thinking, however; there were some
> excellent special-purpose languages in the 1980s that didn't survive
> because they didn't have a viable user and developer community, despite
> being ideally suited to their task.
> Frankly, finding out what the current state of play is (how many XSLT
> developers are there?) is hard enough without even trying to predict how
> that state will change in the future.
> Michael Kay
> Saxonica
> mike@xxxxxxxxxxxx
> +44 (0) 118 946 5893
> On 11 Sep 2014, at 15:46, Matthew L. Avizinis matt@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>  Hello all,
> One of the primary uses of XSLT is transforming xml to html, it seems
> like.  I don't have data handy, but based on what I've read on this list
> over the past dozen years or so, seems like a reasonable enough conclusion.
> I've recently been reading about X-Tags, Polyfil, Web Components, etc.,
> and tinkering with it. (for instance, x-tags.org, webcomponents.org, and
> https://developer.mozilla.org/en-US/Apps/Tools_and_frameworks/x-tags).
> It seems like pretty cool stuff and it occurs to me that by using it one
> could pretty much eliminate the use of xslt for such transformation, if I
> understand it correctly.  From my own perspective, it occurred to me that
> an xul and xslt based xml editor (from the now-hibernated Etna) and content
> management system interface I was working on for my employer until about a
> year ago, could instead be refactored using web components.
> 1) Do you think the web components concept will catch on widely?  2) will
> they be supported by browser developers natively eventually, do you
> suppose? and finally, 3) do you think it will as a result have a major
> effect on the use of xslt, resulting in it's decline?
> Thank you in advance as always for your considered and often witty
> observations.
> --
>   Regards,
> *Matthew L. Avizinis*
> Gleim Publications, Inc <http://www.gleim.com/>
>  <profile_image.png>
>      XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://-list/293509> (by email)
>   XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <-list/994096> (by
> email <>)

Current Thread