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:
https://docbook.svn.sourceforge.net/svnroot/docbook/branches/api.
The new schema is in api/docbook/relaxng/api/src (in RNG as well as RNC
format).
I still need to clean that up a little and document it (as well as the
stylesheets), before it can be merged into trunk.
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
