Re: Modes (or lack thereof)

Subject: Re: Modes (or lack thereof)
From: Mark_Overton@xxxxxxxxx
Date: Wed, 19 Aug 1998 11:39:11 -0400
The queue formatting object  does look interesting.  When building an RTF
output format I had to create a similar structure to support headers and
footers, etc.  I am glad this is specifically included in the spec.  What I
don't understand is how the "output stream" gets split into two queues.
Can I switch back and forth?  For example, when I hit a chapter title do
1. Add a list-item to the "TOC" queue
2. Add a paragraph to the "Body" queue for the heading

If what I think you are saying is true, this means the flow through the
rules is different than before.  A rule would be creating two seperate
parts of the document at the same time.  I will try to ponder this for a
while but it seems a little strange at first.  I am used to building the
document linearly.  First the title, then the TOC, then the chapter, then
the ...

Do you think this will add or detract from the conceptual clarity when
building stylesheets?

I think it would be really helpfull if someone from the group gave a more
conceptual explanation of some of these concepts.  Multiple examples would
also really help.


Chris Lilley <chris@xxxxxx> on 08/19/98 10:52:24 AM

Please respond to xsl-list@xxxxxxxxxxxxxxxx

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Mark Overton/PTSLS)
Subject:  Re: Modes (or lack thereof)

Mark_Overton@xxxxxxxxx wrote:
> I don't want to be negative but...
> Why is the "mode" capability missing from the new spec.  This is one of
> most important aspects of XSL.

Those two statements can't both be true ;-) but I know what you mean, I

> The ability to use the same XML element in
> different places in the output, using different style rules, is crucial.


> This missing functionality is the primary reason why the MSXSL processor
> of limited use.

Could be.

> Maybe I'm missing something in the spec

I suspect so although all the pieces are not there yet and those that
are might not have the names you expect.

> but how would I do something like:
> use the chapter headings in a table of contents and also show up at the
> of a chapter.

Look at the queue formatting object [1].

|> 3.7.1 Purpose
|> A queue is used to gather content flow objects to be
|> assigned to (placed into) a given area or set of
|> chained-areas.

and notice the text which says:

|> A queue shall not be allowed within the content of any
|> formatting object except a page-sequence.
|>      Ed. Note: This restriction applies only to the July
|>      1998 Draft.

Then look at the simple page master formatting object[2] (which gives
you canned regions) and the page sequence formatting object [3] which
holds these together.

Now imagine a new page master which is not "simple" ie you get to define
your own regions on the page and note the text which says:

|> Sequences:
|>           Ed. Note: A method to define the
|>           sequencing of page masters will be
|>           provided in a future draft.

and imagine defining a page master for your TOC and assigning a queue to
it, and imagine

>In the TOC I want it as a list-item and in the chapter I
> want it as a heading.

Yes, that sort of thing is fine. A single element in the source tree
maps to two different formatting objects in the result tree; inheritence
of styles is in the result tree (unlike CSS where inheritence is in the
source tree, although the source and result trees are so closely related
in structure with CSS that you can think of there being just one tree).
So the TOC is one subtree and if all its children are to be formatted as
list items in 8pt/10pt Helvetica then the heading content in the TOC
will inherit that style. And in the chapter, if all chapter headings are
in dark green 16pt/18pt Hattenschweiler then the header content will
inherit that style.

> I don't want to seem ungratefull to the working group for thier time and
> effort.

You don't sound ungrateful, and the Working Draft has been released to
the public precisely to get feedback on it.  If you see obviously
missing functionality, say so. Of course, some (much) functionality is
missing because we haven't got a good general design for that part of
the functionality yet.

For example bidi embedding and multi columns are not in the current
draft - not because these are considered unimportant, but because we are
still designing how there would work.

> There are some very good things in this spec.

It would be helpful to hear what people think is good or useful (and
why) as well as  what you think is unclear, bad, or not useful.

> As I built our XSL
> processor I found many things which the old proposal didn't address.

Like a complete lack of actual flow objects for example ;-) Hopefully
the new spec which replaces the submission is seen as an improvement.

>  The
> IDAnchor is a good example.  I had to create my own version of this to
> allow a "jump" to an element using its ID.  The attribute value templates
> solve another problem I had to create a work-around for.  So, I can see
> they put alot of thought into the draft, but still, the lack of modes
> incomprehesible.

There might be modes in a future draft or there might not, I can't say
since the new draft is not yet written. What I can do is point to things
in the current draft which might be helpful and which might give a
different way to achieve similar results as modes.

Speaking for myself not as an announcement from the Working Group.


Chris Lilley, W3C                   
Graphics and Stylesheets Guy      The World Wide Web Consortium              INRIA,  Projet W3C
chris@xxxxxx                       2004 Rt des Lucioles / BP 93
+33 (0)492 387 987         06902 Sophia Antipolis Cedex, France

 XSL-List info and archive:

 XSL-List info and archive:

Current Thread