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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-apps] GSoC 2011 project idea: DocBook Slides 5.0

On 2011-02-25 10:24, Gabor Kovesdan wrote:
> Em 25-02-2011 14:55, Stefan Seefeld escreveu:
>> I think it's important that the slides vocabulary is a super-set of 
>> the existing DocBook, to allow users to incorporate existing document 
>> chunks into their slides.
> Actually, in my opinion it isn't a superset (some normal DB elements 
> aren't applicable) neither a subset (there will be 
> presentation-specific elements) but has as big intersection with 
> normal DB as possible. If you want to talk in terms of set theory... :)

Fair enough. :-)

>> However, I also recognize that this medium has particular 
>> requirements that run somewhat against the main philosophy of DB: a 
>> clear separation between content and style. Arguably, for 
>> presentations, style *is* content.
> Yes, this is a bit contradictory. I think it's better to talk about 
> content, structure and style, where structure is somewhere between 
> content and style. It's more than content but it isn't the concrete 
> style at all, e.g. sectioning or in normal DB <footnote> specified 
> that its content will be rendered at the bottom of the page, so it's 
> not just content but not a concrete style either. It's structure. I 
> intend to add content and presentation-specific structure elements but 
> keep the style elements minimal. If a given slide of the presentation 
> has a different style (transition, animation, etc.) it will be 
> necessary to distinguish it so the markup has to add support for them 
> but imho it should be kept minimal in the markup and mostly done in 
> the stlysheets. E.g. assigning classes to particular slides but only 
> define the rendering of the given class in the parametrized 
> stlysheets. In this manner, it would not violate so much the original 
> philosophy. We already use such in normal DB, like setting the role 
> attribute of personname to "family-given".

I totally agree to this approach. (Let's just try to avoid having to use 
that (in-)famous "role" attribute altogether !)

>> Thus, I think one area where an updated slides vocabulary may grow 
>> some new elements is support for styling. In the simplest case that 
>> could mean additional hooks that styling info may be attached to (via 
>> CSS, javascript, or whatever else is used to apply styles to the 
>> final slides).
> Yes, I'm thinking of something similar with hooking but keeping the 
> formatting info in the stylesheet parameteres as much as possible.
>> Following last year's work on a new "API documentation profile", I 
>> believe the best way forward is to turn the existing slides extension 
>> into a proper DB5 extension profile, where such additions can more 
>> easily be supported.
> I have also been thinking whether to make an individual schema or an 
> extension. Is last year's work available somewhere so that I can take 
> a look how it was done?

It is. The entirety of that work is kept in the "api" branch: 
The new schema is in api/docbook/relaxng/api/src (in RNG as well as RNC 

I still need to clean that up a little and document it (as well as the 
stylesheets), before it can be merged into trunk.



       ...ich hab' noch einen Koffer in Berlin...

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]