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

["M. David Peterson" <xmlhacker@xxxxxxxxx>]

Wow!  Quite the thread!  A lot of heavy weights in which I have a TON
of respect for have unfortunately provided you with advice that
focuses squarely on the server, suggesting in some cases client-side
is okay.

The reality?

The more XML you *CAN* push to the client, the less load you put on
your server = more clients are able to be served in less time because
the server resources are available in greater quantity at any given
time.

If this question was asked a year ago, there would be no question --
the client support simply did not exist on all major browsers.

Today -- it does.

What does this mean then?  It means that you can push more data
processing to the client.

Does this mean your server no longer needs to process and transform
XML?  Nope!  In fact, server side processing using XSLT becomes even
more of a legitimate solution for one very important reason: XSLT is a
mature language with FAST server side processors.

Here's the rule of them: All browsers based XSLT should be focused on
rendering HTML/XHTML.  The server should then be used to make quick
and simple data requests for smaller pieces of data that a server side
XSLT 2.0/XPath 2.0/XQuery 1.0 engine like Saxon can process EXTREMELY
efficiently using a combination of precompiled XSLT, XPath, and
XQuery.  There are more reasons than this, but here are the primary
areas that often become neglected:

- Browsers do a good job of caching XSLT, so one file request can
equate to well over a megabytoe of bandwidth savings per client over
the course of a few months, dependent, of course on how busy your site
is.  When a static XSLT file request is made, if nothing has changed,
not data is sent. A 50K XSLT file * 10 visits per month = 500k * 3
months = 1500k.

- With this in mind, add to this that a chunk of prerended HTML/XHTML
weighing in at, for example, 35-50k, is now being rendered on the
client using a precached XSLT file and a chunk of XML data that in a
majority of cases is between 1/3 to 1/2 the size.  In cases where the
request invokes a dynamic server side transformation, you also need to
add into the equation the processor savings that take place.

The rule of thumb?  When possible (and in most cases it is) render the
HTML on the client.  When not (as is the case for search engines --
yes, this is true -- Google, MSN, Yahoo!, etc... do not rendering your
XML data using the provided XSLT file.  This means you need to do this
for them.  When a reputable search engine makes a request, you simply
need to send them the prerendered HTML file.

However, you do need to keep in mind that what you send to the search
engines mirrors exactly what is being rendered on the client.  Through
various techniques, its pretty easy to tell when the client is
clicking links that do not exist in their cached copy of your web site
= Being tagged as someone trying to serve content that is "juiced" for
the search engines = being blacklisted.

Of course, with the ability to provide Google a site directory file,
and data feed formats becoming much more prevelant, and as such, more
alternative representations of the same data are being made available,
the search engine are adapting and becoming smarter to the fact that
more versions of the same file CAN and DO exist, and therefore are
allowing for this a lot more than they used to.  But theyre smarter
now to, so those who try to use this to their dishonest benefit, are
not gaining any headway.

Other points to consider --

- More and more clients accessing the internet are mobile-based
browsers which are provide extensive support for client-side XML
rendering technologies such as SVG.
- More and more clients accessing the internet are hybrids -- Feed
readers are a good example of this -- that are focused more towards
accessing Atom and RSS feed formats...  As demand for this increases,
your need to diversify your formats offered will increase.
- Its not just about client-side XSLT, and in fact in many cases its
about CSS, SVG, or a combination thereof.
- XUL and XAML are also on the rise.  The release of Windows Vista
will increase the need to provide a XAML-based version of your data
set.
- When this happens, you will also have a much more extensive base of
client-side XSLT processors that are limited to the same "play it
EXTREMELY safe!" constraints that are necessary to the browser world
as these clients are being built upon more advanced technology that
incorporate secured identity technologies that enable a higher level
of trust to be invoked.
- Advanced data base technologies allow for extensive in-process
transformation of data.  Examples of this exist in SQL Server 2005 and
SQL Server Express -- The client side *FREE* version of SQL Server
that allows for extensive integration of applications that are data
intensive as the client-side processing power, coupled with the speed,
security, and reliability of the DB > DB connections offers a *VERY*
intriguing opportunity for application developers to bring web-based
applications to a whole new level of performance and security.

I could go on... for a long, long, REALLY long time... but I save you
all from the torture.

The bottom line - Diversify now and prepare for change.  Begin to
build an agile foundation that is focused on the delivery of raw data
to the clients which will then allow the users to define how *THEY*
want to view it, instead of how *WE* specficy *THEY MUST* view it.

Make the base of this foundation a combination of client-side and
server-side XML transformation and query technologies that include a
mixture of XSLT 1.0, 2.0, XPath 1.0, 2.0, XQuery 1.0, for Windows/.NET
add to this LINQ and XLINQ.

The future web is data-centric with the ability for the client and
server to work together to abstract semantic information from this
data.  With this in mind, moving towards data formats such as Atom and
RSS and away from serving hard coded/structured formats is the key to
survival.

The end. :)

On 3/3/06, Nathan Young -X (natyoung - Artizen at Cisco)
<natyoung@xxxxxxxxx> wrote:
> Hi.
>
> I would second both points. and add a third which is browser
> compatibility/support.
>
> A client side transform creates a situation that can also be created
> using javascript DOM methods.  The visual page you see in your browser
> window is based on a "generated" dom for the page that's different from
> the page source itself.
>
> Google
> --------------------------------
> Google doesn't authoritatively address how it treats pages that behave
> this way, I suspect because it can be a very complicated issue.  I have
> heard rumors that the google crawler is starting to execute some types
> of javascript as it indexes and so certain kinds of generated content
> may get indexed now when they previously had not.
>
> Their guideline for webmasters suggests that looking at the page in lynx
> is the best way to see what the crawler will do:
>
> http://www.google.com/webmasters/guidelines.html
>
> Accessibility
> ---------------------------------
> As far as accessibility, it is true that JAWS reads the generated DOM as
> displayed by IE.  In that case the accessibility of the generated
> content is what is important, as Didier pointed out.
>
> However, if you have ever seriously looked into accessibility, you'll
> know that it's not that simple.  Satisfying the letter of the
> accessibility regulations (section 508), to say nothing of actually
> making a usable site, involves more than supporting blind users with
> modern computers and the newest licensed version of the JAWs
> screenreader.
>
> For one thing, any content or functionality that depends on javascript
> must be available in another form.  There are numerous other hard
> requirements, but to really get inside the requirements, it helps to
> think about the users you plan to support.  Here's a list of personas:
>
> http://diveintoaccessibility.org/by_person.html
>
>
> Browser Compatibility
> ---------------------------------
> If you are supporting limited XSL functionality on either IE or firefox
> you can probably do things client side.  If you need to support complex
> functionality on both IE and firefox, things will get expensive and time
> consuming quite quickly.  If you need to support other browser
> platforms, you will probably hit a brick wall.
>
>
> ----------->N
>
>
> .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
> ||:.
>
> Nathan Young
> CDC Site Design & Development->Interface Development Team
> A: ncy1717
> E: natyoung@xxxxxxxxx
>
> > -----Original Message-----
> > From: Neil Williams [mailto:linux@xxxxxxxxxxxxxx]
> > Sent: Friday, March 03, 2006 8:04 AM
> > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [xsl] Is letting the browser transform XML to
> > XHTML using XSLT a good choice?
> >
> > On Friday 03 March 2006 3:38 pm, Didier PH Martin wrote:
> > > You said:
> > > 1) Google is based on the source code, and will ignore your
> > webpages.
> >
> > > I reply:
> > > Are you sure of that? How do you know? Is this confirmed by
> > somebody else?
> >
> > Put this into Google:
> > codehelp XML language syntax
> >
> > The page you will get back has only a link to the HTML page.
> > There is an XML
> > page, using browser-side XSLT to convert to XHTML but Google
> > doesn't know
> > about that. If the HTML page had not been created for non-XML capable
> > browsers, Google would not know anything about it. For some
> > time, I had some
> > example pages that only existed in XML. Those pages simply
> > did not exist in
> > Google.
> >
> > My way around this was to implement some PHP scripts that
> > output XML if the
> > browser claims to support it, HTML to others and WML to
> > mobiles. Google only
> > sees the HTML output.
> >
> > > You said:
> > > 2) Blind people's screen readers are based on the source
> > code, and will not
> > > be able to use your webpages.
> > >
> > > I reply:
> > > Which browser are you referring to?
> >
> > A good test browser is lynx. If your site isn't usable in
> > lynx, it will cause
> > difficulties for those with more limited browsers. It's not
> > nice to assume
> > that others have the ability or skill to use a "recommended"
> > browser. Build
> > for everyone, not just your friends.
> >
> > > Hence, if they are using
> > > usual web browsers and Braille readers (like JAWS for
> > example), they will
> > > have access to the text included in the web page.
> >
> > In my case, the text of the XML alone can leave a visitor
> > stranded without
> > obvious means of navigation. XML isn't a web page, it's a
> > data document.
> >
> > > For instance, to get
> > > access to the "title" or the "alt" attributes of an <img>
> > element. In other
> > > words, they have access to the result of the transformation.
> >
> > It's not always a good decision to expect everyone to have
> > such luxuries.
> >
> > > Braille reader. So, if people with this kind of disability you know,
> > > actually use a browser accessing only the source of web
> > pages, then do them
> > > a favor and tell them about more modern tools like, for
> > instance, the one I
> > > mentioned.
> >
> > IMHO it's better to provide content that visitors can use
> > without specialised
> > software.
> >
> > http://www.anybrowser.org/campaign/
> >
> > --
> >
> > Neil Williams
> > =============
> > http://www.data-freedom.org/
> > http://www.nosoftwarepatents.com/
> > http://www.linux.codehelp.co.uk/
>
>



--
<M:D/>

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