xsl-list
[Top] [All Lists]

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

2006-03-03 14:32:25
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(_at_)cisco(_dot_)com> 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(_at_)cisco(_dot_)com

-----Original Message-----
From: Neil Williams [mailto:linux(_at_)codehelp(_dot_)co(_dot_)uk]
Sent: Friday, March 03, 2006 8:04 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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/


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--





--
<M:D/>

M. David Peterson
http://www.xsltblog.com/
<Prev in Thread] Current Thread [Next in Thread>