OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Future of XSL-FO at W3C??

[ Lists Home | Date Index | Thread Index ]

On Friday 18 October 2002 4:54 pm, Paul Prescod wrote:
>
> Let's go back to the real problem. The real problem is that there is a
> person interested in the "style" of the output who doesn't want to learn
> XSLT. Fine. They already know CSS. That's fine too. But it doesn't imply
> that they never have to learn anything OUTSIDE of CSS. The designer of
> the XSLT can merely define a simple XML input format that looks
> something like this:

I see what you mean. Like there are two tiers of stylesheet designer - one who 
will create and test the XSLT on a raft of 'Lorem ipsum' sample input and 
then send an invoice in from a sunny distance. Then the other sort who 
actually hangs around for a pay cheque every month (think they're called 
'staff' in some places) who might not comprehend everything in the original 
masters, and would like to implement a simple level of style nudging.


> <standard-block-style space-before-points="5" space-after-points="3"/>
> <Section2-block-style space-before-points="7" border-start-color="red"/>
> <body-block border-start-width-points="1"/>
> <Title width-points="44" height-points="75" ...>

The thing is, what if the 'simple change' requested is 'simply rearrange these 
pages on the flat plan' which translated turns out to be something more in 
the order of dabbling with the repeatable-page-master-alternatives and 
conditional-page-master-reference children. This isn't style, it's structure 
in effect. Poor person. On the other hand, if they just want to make their 
fonts bold, you're right - a CSS override would assist.


> In other words, you define the customization parameters that will be
> input to your stylesheet (you could also use XSLT
> params/variables/inclusions for the same thing). Then the person who is
> afraid of XSLT does not use XSLT.

Well, to be honest, I hope implementations sprout to the degree that people at 
the art level can be doing stuff like this using a proper production tool, 
not a text editor, such as a future GoLive (the Workgroup Web Server aspect) 
or a future InDesign or a future QuarkXpress. 

Stylesheet designing is an odd thing - instead of hand-on per publication 
issue, then strip all the content out of the last issue and repopulate it 
with this months before remembering that you once made a template for such 
purposes, you're dealing with a rigorous door policy, and if your editorial 
is on the list, it gets in. Once in, it's in the army now - it'll look how 
the designer designed it. However, the delivery stage is apt to drift further 
back down the production process to the extent that like web pages, the 
delivery of the printed matter might only occur once a server has been 
requested of it. 

Hopefully, a designer-level user-interface might aid the stitching up of the 
right XSLT stylesheet with ease, then we'd hear no more of this CSS 
overriding kludge. But in the meantime, yes, might make sense.

-- 
Ian Tindale




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS