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

Re: [xsl] Is letting the browser transform XML to XHTML using XSLT a good choice?

---

---

on October 20th of *LAST* year)

On 3/4/06, M. David Peterson <xmlhacker@xxxxxxxxx> wrote:
> Actually, my studies shown in the article linked to before prove that,
> in fact, you can develop solutions faster when you single out each
> client, take the base solution that works for a majority of the cases,
> and then spend your time debugging each browser, instead of trying to
> write one solution that fits all.
>
> I have quite literally watched a project take 6 months longer than it
> should have because they were dead set on making one code base work on
> all browsers.  If they had stood back and found the common ground the
> could rely on, to then fine tune for each of the supporting browsers
> (there are only four major browser engines (although in the case of
> Mozilla there are several implementations -- but they still use the
> same engine) - IE, Mozilla, Safari/Konqueror, and Opera 9.0 PR1/2, and
> eventually the final -  that support client side XSLT -- but this
> constitutes well over 99% of all browsers in use.  Of course there are
> versions as well, but this in fact is one of the primary problems with
> creating a one size fits all solutuion -- browser versions introduce
> an entirely new layer of developer hello that i, generally speaking
> the biggest problem in regards to time consumption.
>
> Take a look at both my own article on this:
> http://www.xsltblog.com/archives/2005/12/finally_someone_1.html
>
> And more importantly, the newly "Browser Grading" guide published
> study by Yahoo!: http://developer.yahoo.net/yui/articles/gbs/gbs.html
>
> Coming from someone who has just spent the last year of his life
> studying the intimate details of each and every browser on the market,
> I have come to the absolute conclusion that the notion of developing a
> one size fits all (or most) simply does not make sense any more.  The
> cost of attempting such efforts is so disproportionate to the cost of
> fine tuning the standard base on a per browser basis, its not even
> funny.  In many cases (speaking at the corporate development level)
> we're speaking in terms of several million dollars in additional cost,
> and a range of between 3-9 extra months of development.  I have
> personally been able to develop individualized solutions that use a
> common core code base, that is then tweaked for each browser, in less
> than a weeks time on my own.
>
> It just doesn't make sense any more.  I will admit that this has been
> a recent change (Safari gains XSLT support last January, Opera 9.0 PR1
> on October 20th of this year) -- but recent or not, its still a
> change, and a necessary one to maintain any sort of competitive
> advantage.
>
> In my mind, the day this all became a true reality was October 20th.
> Opera has had significant political resistance to implementing an XSLT
> solution within their browser.  The fact that they now have I believe
> speaks volumes in and of itself.  Why go to that expense, and give up
> the politics, if its not seen as crucial to their ongoing competitive
> success?
>
>
> On 3/4/06, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> > > I am, today, very very surprised that this basic
> > > functionality is still not
> > > there, is it because:
> > >
> > > a) Actual players have vested interests in a mainframe like
> > > architecture?
> > > b) People lack imagination with XSLT based technologies and
> > > nobody thought
> > > about this simple feature?
> > > c) software producers are sleeping on the switch?
> > > d) XSLT is unpopular
> > > e) an asteroid felt on earth and anybody with the will to do it was
> > > destroyed?
> >
> > It's none of the above: it's because of costs and risks.
> >
> > I think most of us can see that doing transformation on the client makes
> > sense in principle. But the problem is that you have much more control over
> > the server than you have over the client. As soon as you do things on the
> > client you have to cope with a bewildering variety of versions and variants,
> > and this is a nightmare for quality assurance and potentially for support
> > costs. Also, it means you have to put up with using highest-common-factor
> > technology: you can't use technologies like XSLT 2.0 until five years after
> > they emerge, despite the huge productivity gains they bring. (XForms and SVG
> > suffer from the same issues.)
> >
> > So it's not an easy choice, and there's no single answer that's right for
> > every project.
> >
> > The option of doing both - client side when possible and server side
> > otherwise - is one way forward, but it adds to your overall system
> > complexity and cost.
> >
> > Michael Kay
> > http://www.saxonica.com/
> >
> >
>
>
> --
> <M:D/>
>
> M. David Peterson
> http://www.xsltblog.com/
>


--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---