Re: Linking to stylesheets in XML

> From: "Christopher R. Maden" <crm@eps.inso.com>
> [Jon Bosak]
[...]
> > 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.

Well, I'm always willing to state the obvious, even when I'm wrong.
Straw Dogs 'R' Us:

  <FOO XML-LINK="SIMPLE"           -- |EXTENDED? --
       ROLE="STYLESHEET"
       TYPE="application/dsssl"    -- MIME type or simple name? --
       TITLE="DSSSL - Blues"       -- label for use in popup menu --
       SHOW="[EMBED|REPLACE|NEW]"  -- sets behavior in context --
       HREF="blues.dsl"            -- resource location --
       ACTUATE="[AUTO|USER]"       -- see below --
       BEHAVIOR=""                 -- see below --
       >

Not quite sure what to think of ACTUATE or BEHAVIOR, although BEHAVIOR
seems probably more appropriate than SHOW as a container for how to
specify stylesheet behavior in context. I chose SHOW only because
its existing enumerated values seem to fit. Maybe BEHAVIOR could be 
used for something else.

 
> > 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.

Depends on many factors, but paramount in my mind is what we will end
up doing with transcluded documents/fragments. A stylesheet link could
apply to either the containing entity en toto, as a 'switch' until
another stylesheet is encountered, or an accumulation (given that the
stylesheet itself may specify the application bounds). Obviously, the
whole attempt at 'cascading' in CSS is to manage conflicts between
multiple stylesheets. I don't know enough of DSSSL to comment accurately,
but I assume this same type of conflict management exists.

> >    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
> enumerated.

Agreed. But for the purposes of XML stylesheets, ROLE="STYLESHEET"
would certainly suffice.

> >    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.

Exactly. And I'm not clear why there should be a limitation, anyway.

> > Method 3: The stylesheet attribute
> 
> Yuck.  A simple link wouldn't be (much) harder than this, anyway.

Please don't do this. I think Terry Allen and I would simply barf. Too
many memories of HTML-WG.

[...]
> 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.

Why not use what is already the preferred method in SGML: NOTATION.

  <FOO XML-LINK="[SIMPLE|EXTENDED]" ROLE="STYLESHEET" NOTATION="DSSSL" ...>
  
> Given the 6 April XML-link draft, I'd recommend something like the
> following:
[example elided...]
> 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.

As I mentioned above, this type of conflict management seems more the
province of the stylesheet language itself, although we'd obviously
need to support whatever the stylesheet language needs to disambiguate
the boundaries and priorities, etc.

> > 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.

I'm sure this would seem quite intuitive to WWW users.

> > 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.

I would think there are classes of CSS behavior that simply don't make
much sense in the context of an XML document; we'd either need to disallow
those definitions, or leave that to Hakon et al to write an addendum stating
which parts of CSS will work within XML and which won't.

> > 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.

Agreed. I have and will argue for ID and CLASS to be added to *all* elements
in HTML as part of the requirements for the WAI (Web Accessibility Initiative),
as Braille stylesheets will require the ability to associate all elements.
This would hopefully kill two birds. Different forum, anyway.

> > 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.

I think simply that it must occur within the same entity is sufficient,
given that a processor must grab the whole entity before it can begin. I've
been reading over the SGML fragments draft, and I *think* this would be the
proper requirement. I need to go back and read over the spec again, though.

> 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.

Thanks for using such a pertinent example. Yes, I agree. I simply don't see
the advantage in anything *but* XML-LINK, but am certainly willing to hear
counter arguments in favor of a PI over an element, or whatever other methods
might be attractive. XML-LINK seems an intuitive, simple choice.

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey                    <altheim@eng.sun.com>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 2550 Garcia Ave., MS UMPK17-102, Menlo Park, CA 94043 USA
         "Give a monkey the tools and he'll build a typewriter."

Received on Thursday, 24 April 1997 14:45:50 UTC