[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT vs Web Components

Subject: Re: XSLT vs Web Components
From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 11 Sep 2014 16:14:35 -0000
Re:  XSLT vs Web Components
Hi,

I agree with what Mike and Jim said.

I think web components are pretty cool too. I imagine that some systems
that use XSLT today could probably be built with web components and/or
other emerging web-based technologies. And this is fine. Where I don't see
web components changing things fundamentally is in systems that must
necessarily be committed not only to application development - that is, to
old and new functionalities in operation (whether on the computer or off
it, e.g. print), but also to *long-term* health, development and
maintenance of the data set(s) and processing system(s). Not just on
today's stack, that is, but tomorrow's.

It really depends on who you are. For some, the web is all that ever was
and ever will be. For others, basing your entire content management
strategy on the web still seems like a gamble. Now you might say the same
thing, of course, about XML -- and in some cases you'd be right -- without
appreciating how lots of XML data (and lots of the most valuable XML data)
subsisted in other forms before it was ever XML, and hopefully will remain
available for time to come. Not because XML can express anything you can't
express in some other form of markup -- but only because it can (when used
right) make the parsing problem go away. (Only when HTML5+web components
make the parsing problem go away will they be attractive to true lovers of
their data -- and what that will mean is we will be free to integrate them
into our XML-based systems as yet another interface.)

If your data shelf life is short, by all means, stuff it into an
application or an RDBMS - that's what they are for. But for modeling data
not just to support applications, but for long-term access and maintenance
-- well -- let's just say that web components doesn't touch that problem.
They just move it to a new platform to be "discovered" and solutions to be
"invented".

In particular, one thing that hasn't (to my mind) been adequately tested is
how well we can get "semantic" tagging to work (for real-world documents,
at any rate, not just data buckets) without grammars to validate. That's
more or less what web components offers, as far as I can tell. Maybe we can
sneak grammars in through a side door. I suppose using dot syntax might be
a thrill.

Cheers, Wendell



On Thu, Sep 11, 2014 at 11:26 AM, James Fuller james.fuller.2007@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> 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@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 <http://-list/994096> (by email)
>>
>
>   XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <-list/174322> (by
> email <>)
>



-- 
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.