- From: William F. Hammond <hammond@csc.albany.edu>
- Date: 13 Jan 2002 16:51:38 -0500
- Cc: www-talk@w3.org
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 UTC