W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2002

Re: A Real "XML" website

From: William F. Hammond <hammond@csc.albany.edu>
Date: 13 Jan 2002 16:51:38 -0500
Cc: www-talk@w3.org
Message-ID: <i7bsfxx6l1.fsf@pluto.math.albany.edu>
The following message is a courtesy copy of an article
that has been posted to comp.text.xml as well.

nick@fenris.webthing.com (Nick Kew) writes in comp.text.xml:

> In article <3C40C719.4060608@silmaril.ie>, one of infinite monkeys
> 	at the keyboard of Peter Flynn <peter@silmaril.ie> wrote:
>  
> > You may find some experimental ones, but no-one in their right mind
> > is going to design a public or corporate site that can only be viewed
> > by the technologically literate. This is why server-side transforms
> > are so much more popular.

And so much more sensible as well if we are talking about public web
sites.

> You wouldn't use XML for static pages.  But when you're presenting a
> dynamically generated report, there's nothing to lose by offering users
> the option, and it keeps the server load down if some of them select XML.

If you're serving kiosks in a shopping mall, sure.  But if you're
serving the public at home, this provides too many opportunities for
abuse unless we could assume that default out-of-the-box user agent
processing is merely that for script-free XML styled by CSS.

Otherwise, at the very least, the consumer has no way of knowing how
much of her CPU or RAM is going to be consumed by the client-side
processing that might be triggered unless she is one of the few who
has arranged careful custom handling of XML.

> It is also used 'live' with clientside scripting (javascript) rather than
> XSLT to generate a human-readable report.  Again, this has to be a user
> option, with a fallback to server-generated HTML.

This likewise provides opportunities for mischief when served
publicly.  At the very least let me point out that few user agents
provide the user an opportunity to see what actually is going to
happen, e.g., what anchor might be followed, when a script-activating
widget is selected.

A smart consumer will browse with script handling disabled.

Don't we take these issues seriously now?

A minimal alternative would be for user agents to have front-panel
quick-action toggles for enabling/disabling script handling (for
consumers who think they can discern safety based on perceived content
origin).  Typical option configuration is much too cumbersome for
on-the-fly decisions.

                                    -- Bill
Received on Sunday, 13 January 2002 16:51:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:27 GMT