Re: Linking to stylesheets in XML

[Jon Bosak]

> Method 1: The stylesheet PI

Good for demos, but hacky and not very extensible.  If we document it,
we'll never be able to get rid of it, and there is a far better way.

> Method 2: The stylesheet link
> The leading alternative to the PI approach is to use some kind of
> specialized link.  This has seemed so obvious to everyone that no
> one has bothered to propose specific syntax for it.  I will leave
> this as a challenge for the more imaginative members of the WG.

This is definitely my preferred method.

> Some questions that will need answering are:
>    Does the stylesheet link go in some kind of meta section, like
>    HEAD in HTML?  If so, how is that defined?

Nay, no more than any other link needs to.

>    Is a stylesheet link a normal link with a particular ROLE
>    attribute?  If so, ROLE becomes an enumerated attribute type.

Not necessarily.  Singling out certain role values doesn't mean that
all values need be enumerated, any more than recognition of certain
attribute names for linking means that all attribute names must be

>    Is a stylesheet link always a simple link?  Sometimes a simple
>    link and sometimes an extended link?  (It's easy to think of good
>    uses for extended stylesheet links.)  Always an extended link?
>    Some different kind of link entirely?

I think that simple and extended links should never be distinguished
for applications; otherwise, the power of extended links is reduced.

> Method 3: The stylesheet attribute

Yuck.  A simple link wouldn't be (much) harder than this, anyway.

Stylesheet links provide a host of benefits.  To address Jon's goals:

> 1. Dsssl-o already exists, so while its refinement may be considered
> 2. CSS already exists; it can and will be used with XML documents.

Linking allows either to be used, as well as FOSIs, DynaText
stylesheets, and Q (which I think is the Grif stylesheet language).
(Not that I would recommend use of any proprietary language with XML.)

The question does arise as to how to differentiate between DSSSL-o and
CSS stylesheets.  A separate role for each means that new roles are
needed for any new stylesheet language.  Additionally, it's clear that
if linking more than one stylesheet, a simple link will not suffice.
Given the 6 April XML-link draft, I'd recommend something like the

<!-- styles associates an element with one or more stylesheets -->
<!ELEMENT styles (target, style+)>
<!-- title's meaning is undefined here -->
<!ATTLIST styles
          xml-link CDATA #FIXED    "EXTENDED"
          role     CDATA #FIXED    "XML-STYLES"
          title    CDATA #IMPLIED
<!-- target is a pointer to an element -->
<!-- href is a pointer to the element to which these styles apply
     title's meaning is undefined -->
<!ATTLIST target
          xml-link CDATA #FIXED    "LOCATOR"
          role     CDATA #FIXED    "XML-ELEMENT"
          href     CDATA #REQUIRED
          title    CDATA #IMPLIED
<!-- style is a pointer to a stylesheet -->
<!-- href is a pointer to a stylesheet
     title is the human-readable title of the stylesheet, used for
     behavior is the MIME type of the stylesheet; defaults to
        application/dsssl -->
<!ATTLIST style
          xml-link CDATA #FIXED    "LOCATOR"
          role     CDATA #FIXED    "XML-STYLE"
          href     CDATA #REQUIRED
          title    CDATA #IMPLIED
          behavior CDATA #IMPLIED

<styles title="Root Styles">
   <target href="#ROOT"/>
   <style href="foo.dsl" title="Foo View"
   <style href="foo.css" title="Foo View" behavior="application/css"/>
   <style href="diff.dsl" title="Different View"

The first stylesheet referenced should be considered the default, if
usable.  An application could permit users to switch between
stylesheets, perhaps removing stylesheets whose syntax it did not
understand.  Stylesheets linked with child elements take precedence
over those linked with parents.

> 3. DSSSL allows a single specification to contain multiple
> stylesheets, but CSS does not, so there must be a way to point to
> multiple stylesheets that use a single stylesheet language as well
> as to multiple stylesheets using different stylesheet languages.

I don't see a problem with James Clark's use of foo.dsl#ident to refer
to the stylesheet "ident" in the file "foo.dsl" as part of phase 3.

> 4. CSS allows for style specifications to be embedded directly in
> the start-tags of the elements to which they apply.  I have argued
> in the past that this will be very common in XML documents generated
> from databases, but now I'm not so sure.  Do we allow this in XML
> documents?  If so, how?

Yucko.  I would just not mention it.  Since XML allows definition of
one's own document types, nothing will stop users from doing this if
they need to, but I don't see a need to encourage it.

> 5. I have been informed by someone who watched a discussion of this
> take place in the html-wg that there is a requirement for
> stylesheets to be associated with specific parts of a document.
> (Makes sense when you think about it.)

Using the linking specification makes this trivial.  The example above
can easily accomodate this.

> 6. The performance implications of different methods for calling in
> and applying stylesheets are beyond my ken, but there surely must be
> some.  The implementors among us should be careful to consider the
> impact of the various approaches on the way that documents will
> actually be rendered.

I would recommend in the specification that the extended link group
associating stylesheets with a given element occur before the element,
if it occurs in the same document instance.

The linking method meets all of these goals, plus allows a systematic
way to associate new stylesheets with others' documents.  If I am
visually impaired, and the data publisher did not create an audio
stylesheet, I can create one myself.  I would associate that
stylesheet with the document by creating an extended link group in
another document; stylesheet creation tools would do the same.  This
would also allow me to easily share this stylesheet with other members
of my community.


Christopher R. Maden                  One Richmond Square
DynaText SIT Technical Support        Providence, RI 02906 USA
Inso Corporation                      +1.401.421.9550 (voice)
Electronic Publishing Solutions       +1.401.521.2030 (facsimile)

Received on Thursday, 24 April 1997 10:57:12 UTC