[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Modes (or lack thereof)

Subject: Re: Modes (or lack thereof)
From: Chris Lilley <chris@xxxxxx>
Date: Wed, 19 Aug 1998 16:52:24 +0200
chris lilley new show
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 the
> most important aspects of XSL. 

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

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

Agreed.

> This missing functionality is the primary reason why the MSXSL processor is
> 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 top
> 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 seems
> 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.

[1] http://www.w3.org/TR/1998/WD-xsl-19980818#AEN2087
[2] http://www.w3.org/TR/1998/WD-xsl-19980818#AEN1663
[3] http://www.w3.org/TR/1998/WD-xsl-19980818#AEN1605

-- 
Chris Lilley, W3C                             http://www.w3.org/
Graphics and Stylesheets Guy      The World Wide Web Consortium
http://www.w3.org/people/chris/              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:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.