Associating stylesheets with documents

Way back on April 23 the ERB discussed methods for linking stylesheets
to documents and decided to take a two-tiered approach: adopt a method
based on processing instructions and already implemented
experimentally for the simple cases, and work to define a more
elaborate method based on some kind of "binding document" for the more
complex cases.  This would allow us to quickly put in place a simple
mechanism for the typical case while giving us more time to come up
with a good design for the tougher but less common cases.

I should have reported this decision, but some details remained to be
specified, and then we got embroiled in the error-handling controversy
while simultaneously trying to steer the WebSGML TC through WG8 in
Barcelona, and stylesheet linking just sort of fell through the
cracks.  I brought this back up during last Wednesday's ERB meeting,
and we made sufficient progress to finally report to the WG (and early
implementors) where we currently stand and where we seem to be headed.

The simple mechanism is easily described. A stylesheet is associated
with an XML document by inserting into the prolog of the document a
processing instruction of the form

   <?XML-stylesheet type="text/dsssl" href="duckbook.dsl"?>

where

   type   specifies a stylesheet language such as text/dsssl or text/css
   href   is a system identifier such as a file name or URL

Thus, a typical XML document might begin:

   <?XML version="1.0"?>
   <!DOCTYPE chapter SYSTEM "duckbook.dtd" [
      <?XML-stylesheet type="text/dsssl" href="duckbook.dsl"?>
   ]>
   <chapter><title>....
   </chapter>

XML-stylesheet processing instructions can appear only in the document
prolog; if they appear anywhere else, they are simply ignored.  Note,
however, that under the rules for XML prologs, the following would be
legal:

   <?XML version="1.0"?>
   <?XML-stylesheet type="text/dsssl" href="duckbook.dsl"?>
   <chapter><title>....
   </chapter>

This simple method has already been implemented in Jade and in
HyBrick, the SGML/HyTime/DSSSL Web browser demonstrated by Fujitsu
Labs at WWW6.  In last week's ERB meeting, we informally agreed that
we need to add the following in parallel with the latest WD-style
draft (http://www.w3.org/pub/WWW/TR/WD-style-970324):

1. An optional MEDIA attribute with the same semantics as the MEDIA
attribute specified in WD-style.

2. An optional TITLE attribute with the same semantics as the TITLE
attribute specified in WD-style.

3. A form <?XML-alt-stylesheet ... ?> with the same semantics as
REL="alternate stylesheet" in WD-style.

Note that WD-style uses the TITLE and MEDIA attributes to group
stylesheet options for the user in various ways and to indicate (in
conjunction with the REL attribute) whether a stylesheet is
"persistent," "default," or "alternate."  The specification of these
interactions in WD-style appears to me to assume certain features of
CSS that may or may not apply to DSSSL; this could need some further
exploration.

One question that certainly needs resolution is the implied meaning of
multiple stylesheet PIs.  The corresponding structure in WD-style (a
series of LINK REL=stylesheet elements) specifies a cascade of the
stylesheets in the order in which the LINK elements appear in the
HEAD.  The alternatives here seem to be:

1. Make the appearance of more than one xml-stylesheet PI in a prolog
an error.  (You could still have multiple xml-alt-stylesheet PIs.)

2. Allow multiple xml-stylesheet PIs and cascade them if they are
written in a language such as CSS for which cascading has been
defined, but leave the behavior system-dependent if they are not.  (No
cascading rules have been defined for DSSSL, but there seems to be
nothing preventing this at some time in the future.)

3. Allow multiple xml-stylesheet PIs but either

(a) state that the various stylesheets should always be presented as
user options, or

(b) allow the treatment be completely system-dependent.

One argument for approach #3 is that user agents that can cascade
stylesheets are probably significantly harder to implement than user
agents that simply allow the application of alternative stylesheets,
and our emphasis on simplicity means that we won't require user agents
that support stylesheets to also support cascading.

Another question is what to specify as the behavior when multiple
stylesheet PIs are given and they are of more than one type.  This
could be decided by the system, the user, or some combination of the
two.  For the near term, it would seem sufficient to state that the
behavior is currently considered to be system-dependent and that we
intend to sort this out later.

As for the more complex "binding document" approach, that's on hold
until we can confer with other W3C activities having similar
requirements to see whether we can arrive at one solution that will
work for all of us.  Given everything else that's happening right now,
it will probably be a couple of months before we get to that.  But the
simple method above should carry us well into the initial wave of
stylesheet implementations if we can get some resolution of the open
questions just stated.

Jon

Received on Saturday, 14 June 1997 22:14:32 UTC