RE: WCAG 2.0 -> 3 - Bottom Layer (Server Side Techniques)

-----Original Message-----
From: Mirabella, Mathew J

There seems to be a large number of languages to choose from when it comes
to scripts on the server or on the client side.

Should we then be specific about the language and include jsp, asp,
javascript, perl script, c, java and vb script.  Do we want to only focus on
a subset of thees languages (say JSP and javascript only), or do we look at
this subset (say javascript and jsp) as the core where comprahensive
techniques "must" be available, and provide a forum for people to contribute
with techniques in other languages which "may" be made available but don't
strictly have to be.

In addition to the list of technologies, should we include xsl (xslt)
techniques as well.  (Maybe DTD?).

should we go further and include voiceML and MathML as we are doing with
other xml languages such as xhtml and svg.

And.... when we look at techniques with given languages, should we be
specific about the version refered to such as css 1 or 2, html 4 or xhtml 1,
etc.


I'm not talking about client side or server side scripting; I'm talking
about server configuration and management and the techniques of managing
content via the server configuration.

There are a number of things that can be done on the server side through
proper configuration and management, whether it be Apache, MSIIS, iPlanet,
whatever (but not PWS).  You can do them either by managing the server's
configuration directly, of if you do not have access or permission to the
server's configuration, you can implement many of these techniques via
placing the server directives in a .htaccess file in various directories.
The server always looks for these files in the directory tree and addresses
the content accordingly.

It's true that sometimes these issues are addressed via server side
scripting, and sometimes it is necessary to do that, only because the
developer cannot implement that procedure any other way.  But this is
actually a poor method of implementation and reflects poorly on the
organisation as a whole.  It shows an inability to develop good procedural
policy and strategies for managing their web content.  It is far more
effective to do these things through server configuration.  That also allows
the whole server to be better managed, it shows some sense of QA towards
managing the delivery of content, and is somewhat self documenting in that
the server configuration file becomes documentation of the state of content
on that server, else you have to parse heaps of markup to be able to realise
the state of that content.

This type of approach is extremely important in XML content management.  If
you look at the Apache/Cocoon framework it is built on a architecture that
allows one to address these issues;  This framework allows you to deliver
content on the fly, according to the capacities of the UA; for instance, it
could deliver the page in standard XHTML/CSS and GIF for IE, XHTML/CSS and
PNG for Mozilla, and for future Mozilla, when SVG is native, XHTML/CSS and
SVG.  If you want the content in PDF, it will generate and deliver it in
PDF, or pure SVG.  The same content could be delivered in XHTML2 to UAs with
the capacity to render it, without changing the method of delivery to other
UAs that can only manage older DTDs or Schemas.

So in order to understand how to manage and deliver content in this medium
it is very important to understand server side techniques, not necessarily
scripting, but understanding how server, and three tiered architecture
processes HTTP requests, and just what techniques are available to better
enhance web services and accessibility.

Geoff Deering

Received on Tuesday, 26 August 2003 04:14:15 UTC