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).
http://balisage.net/Proceedings/vol13/html/Milowski01/BalisageVol13-Milowski01.html
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(_at_)saxonica(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_at_)saxonica(_dot_)com
+44 (0) 118 946 5893
On 11 Sep 2014, at 15:46, Matthew L. Avizinis matt(_at_)gleim(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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 <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--