Re: Linking to stylesheets in XML

> Requirements are the best place to begin; these occur to me:
> 
> 1. Dsssl-o already exists, so while its refinement may be considered
> the basic work of Phase 3, it can already be experimented with.  Thus,
> we should attempt to standardize at least one form of association that
> can be deployed fairly quickly.  A simple mechanism that associates a
> single stylesheet with a given document might be very useful in this
> regard.
> 
> 2. CSS already exists; it can and will be used with XML documents.  So
> there is a requirement that at least one mechanism for associating
> stylesheets with documents be able to handle more than one stylesheet
> language.  In the general case, one should be able to associate with a
> given document multiple stylesheets that each use a different
> stylesheet language.
> 
> 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.

Agreed.

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

(I'm going to excuse myself up front here.)

I think this is a horrible design.  It doesn't scale.  In my book, that is
reason to throw it out.  We are not building a word-processor format.... so
lets not make it look like one. 

People need to take into consideration that design patterns like this to not
fit well into a scalable and uniform design for high-end needs. 

I say no.  Absolutely not.  Send them my way if they don't agree.... ;-)

(No, I'm not really passionate about this at all.  Not one bit.)

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

Interesting.  This could be done in DSSSL by associating a particular 
element as a pseudo-document-element.

Whenever I hear a requirement like this, I ask: "What are you trying to
do?"  This is a solution to some problem--not a requirement.  What is the
problem they or we are trying to solve?

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

Agreed.

I'll give you another requirement:

7. Legal print documents.  I must be able to deliver semantics for a XML 
document that allows a user to hit "print" and they will get a legal *print* 
document.  I have many clients who absolutely need this.  

We cannot ignore the legal/compliance industries (banking, insurance, etc.).
They have laws which they much comply with that aren't going to change anytime
soon here in the U.S. (or anywhere else?).  ...and they are silly laws.

Things like:  Well, the last page must have a 2 inch bottom margin if
you are printing in Indiana.  In Oklahoma, the "data" of the document must
be in bold and at least 12pt type.  All kinds of state recorders have strange
requirements.

...don't even ask about financial printing!!!

I have clients who are saying: "Lets use XML.  We have already have SGML.
XML means we don't have to down-translate and we can deliver legal print
documents."

...now we just have to deliver on that one.

Thus, there is a big win for us all if we can deliver a solution that can
scale up to this particularly nasty task.


> People should state other requirements if they can think of any.
> 
> Here are some mechanisms for associating stylesheets with documents
> that have been proposed by various people.
> 
> Method 1: The stylesheet PI
> 
> This method was proposed by James Clark for use in the demonstrations
> at WWW6 and has been implemented in the latest release of Jade (see
> http://www.jclark.com/jade) and in the HyBrick HyTime/DSSSL browser
> from Fujitsu Labs.  A stylesheet is associated with a document by
> putting a processing instruction like this in the prolog:
> 
>    <?XML-stylesheet type="text/dsssl" href="foo.dsl"?>
> 
> The prolog might have a doctype declaration:
> 
>    <?XML version="1.0"?>
>    <!DOCTYPE chapter [
>       <?XML-stylesheet type="text/dsssl" href="foo.dsl"?>
>    ]>
>    <chapter><title>....
>    </chapter>
> 
> Or it might not:
> 
>    <?XML version="1.0"?>
>    <?XML-stylesheet type="text/dsssl" href="foo.dsl"?>
>    <chapter><title>....
>    </chapter>
> 
> This is quick and easy, so it might qualify as the simple method for
> quick deployment.  However, there appear to be problems in trying to
> extend this to the specification of multiple stylesheets.  I don't
> clearly understand these problems, but James does.  Pending their
> resolution (if any), the current understanding is that any PI after
> the first valid one is ignored.  It would seem on the face of it that
> there is nothing to prevent having one PI for each stylesheet
> language; the rule would simply be that the first valid PI for each
> type (text/css, text/dsssl) is the one that gets used, and the
> application figures out which flavor it wants.
> 
> It seems clear that we don't want to use this method to apply
> stylesheets to parts of a document; this would put us back into the
> position of thinking of the document as an event stream, which is one
> of the HTMLish things that XML is trying to get away from.  The
> current experimental convention is that any stylesheet PI encountered
> outside the prolog is ignored.

This is why I like the hub document concept...

It is quite easy to imagine that I might want to do something like:

<!DOCTYPE STYLESPEC SYSTEM "stylespec.dtd">
<STYLESPEC>
   <STYLEGROUP ID=S1>
      <!-- if the client application's applicable law state matches
           the below conditions, then use the appropriate DSSSL mode
           as the starting mode. -->
      <CONDITION ID=C1>
         <STATE>Indiana</STATE>
         <USEMODE>indiana</USEMODE>  
      </CONDITION>
      <CONDITION ID=C2>
         <STATE>Oklahoma</STATE>
         <USEMODE>oklahoma</USEMODE>
      </CONDITION>
      <EXTERNALSTYLE HREF="mortgage.dsssl">
   </STYLEGROUP>
   <EXTERNALSTYLE ID=S2 HREF="notice.dsssl"/>
   <EXTERNALSTYLE ID=S3 HREF="security-agreement.dsssl"/>
   <TARGET STYLE=S1 HREF="mortgage.xml">
   <TARGET STYLE=S2 HREF="cosigner-notice.xml">
   <TARGET STYLE=S3 HREF="security-agreement.xml">
</STYLESPEC>

Now, I could embed this in a document... but I'd rather not.  It would
be nice to at least allow a more scalable and uniform style specification
*document*--extending what is defined in the DSSSL standard.

...slap me on the wrist, but, I want to deliver applications to the client
via XML, not just documents to be displayed.  Thus, some of my documents
are instructions.

> 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.  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?
> 
>    Is a stylesheet link a normal link with a particular ROLE
>    attribute?  If so, ROLE becomes an enumerated attribute type.
> 
>    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?

Hmmm, I don't like embedding things in the document.  It means I have to
change the document if I change my mind on style implementation.  My
experience shows that styles change far more frequently.

> Method 3: The stylesheet attribute
> 
> I can't remember anyone suggesting this alternative, but it suggests
> itself as soon as you assert the requirement that stylesheets be
> applicable to particular parts of a document.  If we reject the idea
> that stylesheets are going to be switched on and off with PIs (I do!),
> then the obvious way to indicate the scope of a stylesheet is to
> associate it with a containing element.  For example:
> 
>    <chapter xml-stylesheet="foo.dsl">
> 
> Unfortunately, this doesn't leave us with any clean way to indicate
> the stylesheet language unless we assume a limited number of them
> (which is not unreasonable):
> 
>    <chapter xml-dsssl="foo.dsl" xml-css="bar.css">
> 
> One senses that a further level of indirection may be needed here.
> When it's all over we may discover that this approach is no simpler
> than using extended links to associate stylesheets with particular
> container elements and probably much less general; one can imagine
> using extended links to associate stylesheets with arbitrary spans
> within a document, and while I don't think that this would be a
> particularly good idea for DSSSL stylesheets, it might make sense for
> CSS.  It's possible that the right way to attack this problem is
> through some kind of "inline SUBDOC", which is not on the agenda for
> 1.0 but will almost certainly have to be reckoned with at some point.
> 
> If we are to enable embedded CSS style specifications on individual
> elements, then special attributes would seem almost unavoidable:
> 
>    <chapter xml-css-style="color: blue">
> 
> ...
> 
> Your thoughts and proposals are hereby solicited.
> 
> Personal note: I will be out of email contact from Saturday noon to
> Monday night and then again most of the day Tuesday.  But I'm sure
> that you will have this all figured out by the time I get back.

What I really what is a indirect style specification for any or all of
the above.  I want to be able to define a "token" that I can redefine
later (sounds a lot like public ids).  I know this opens the whole
resolution/lookup problem.... but it is the only way I know to solve
this problem in large dynamic environments without down-translating just
to resolve tokens the the "system-identifier-of-the-day".

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@copsol.com
Copernican Solutions Incorporated                  (612) 379 - 3608

Received on Monday, 21 April 1997 11:05:20 UTC