Suggested additions to XSLT Section 6.2.8 System Functions

XSL Editors,

I've been thinking about the following (which appeared on the xsl-list)
and have come up with a few suggestions which I hope may be useful:-

  "... The proper use of XSL is to determine the user's desired media and
   limitations then produce the appropriate document for that user. (The
   key is "determine the user's desired media and limitations", not
   whether that transformation occurs on a server or on a client.)"

                                       Stephen Deach (personal opinion)
         http://www.mulberrytech.com/xsl/xsl-list/archive/msg04034.html


Section 6.2.8 (System Functions) of the 21st April draft allows  
stylesheets to get information about system environment variables using
system-property(), and availability of functions using 
function-available().

At present the system-property() function can be used to get at one
well-known xsl property (xsl:version) and any environment variables. For a
stylesheet being run on a server via a cgi script, this  may well be
useful in determining whether or not to create formatting objects linked
to certain types of images:

  eg. system-property("HTTP_ACCEPT")

   would return a string containing a comma separated list
   of acceptable mime types.

The HTTP_* environment variables available to cgi scripts are all well
known and well understood.

There are disadvantages to this approach however (tailoring output to the
connecting browser), not least that it is not friendly to caching proxy
servers.


When run on a browser, a stylesheet should be able to get information on
acceptable media types, user preferences, helper applications etc. and
generate a rendering using formatting objects appropriate to the browser -
using the same XML source (ie. caching friendly). 

However, when run as part of a browser, there are no well know environment
variables for the stylesheet to query - so I would like to suggest some
extra (optional) system properties/functions: 

  xsl:media-embeddable("image/gif")
  xsl:helper-available("application/pdf")

    These would indicate whether a particular media type
    is embeddable within the browser and/or viewable
    with a helper application.

    eg. an xsl enabled lynx might return false for
        xsl:image-embeddable("image/gif"), but true
        for xsl:helper-available("image/gif") if the
        user has xv installed on the system.

  system-property(xsl:media)

    returns "screen", "print", "aural", "tty", "hologram" etc.
    (see http://www.w3.org/TR/REC-html40/types.html#h-6.13)
  
    or returns "" if the xsl processor is unaware of the media
    it is being invoked to produce a rendering for.

Some browsers are perfectly capable of displaying certain media types, but
the user has the option of turning whole classes of them off. This isn't
really handled well by 'media'.

  xsl:user-preference("xsl:videos")
  xsl:user-preference("xsl:images")
  xsl:user-preference("xsl:applets")
  xsl:user-preference("xsl:sounds")
  xsl:user-preference("ms:active-x-controls")

    return either "on", "off", or "" if the string wasn't
    recognised.


  system-property("xsl:implementation-class")

    would return information about what sort of xsl
    implementation the stylesheet is running on.

    Returns "server", "browser", "stand-alone" or ""

None of these need necessarily be specified in the XSL recommendation,
since I'm sure that XSL processors in browsers will be be able to use
javascript to do similar things via the <xsl:functions> element and
various vendor specific objects (navigator.mimeTypes[]) etc.

However, I don't think it should be necessary to use javascript just to
allow a stylesheet to decide whether it is going spit out an
<fo:inline-image> with a short description, or an <fo:inline-link> to an
image and a long description. It should definitely be possible to do it in
a standard way that can degrade gracefully when not available.

To this end I think that these functions/properties (or others with
equivalent or better functionality) should be specified in the eventual 
XSL recommendation, so that there is a standard way to get at this sort of
information.

An XSL processor could always return false for:
  function-available("xsl:media-embeddable"),
  function-available("xsl:helper-available") and
  function-available("xsl:user-preference")
and can return "" for:
  system-property("xsl:media") and
  system-property("xsl:implementation-class")
if it didn't support these (or some of these) optional extras or if it.


Anyway, that's it. If you read this far - many thanks! I hope you found it
useful and sensible.

Best wishes,


Paul Fidler
-- 
Cambridge University Engineering Department
Trumpington Street, Cambridge, CB2 1PZ, UK

Received on Wednesday, 28 April 1999 11:05:16 UTC