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: Towards easier stylesheet customizations


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Stylesheets customizations is one of the most difficult aspects in using
DocBook, I think.
Stylesheets writers have been doing an excellent work in providing
parameters to control most important aspects of output rendering in the
various available formats. This is great for people that work regularly
with DocBook, and I think just a little more effort could allow
beginners to create customization layers.

Indeed it looks to me just a little more formalism in the parameters
definition could allow automatic generation of graphical user interfaces
allowing users to graphically set parameters, create new customization
layers and modify them.

Have you heard of such a system for other schemas like TEI or DITA? I
think a standard common to such schemas could be adopted.

I think I have identified 3 categories of parameter for the FO output:

1) general parameters holding simple values, either boolean, numbers,
characters or strings, possibly from a list of possible choices
2) *.properties parameters that define visual rendering of many specific
elements through "attribute-set". This is for FO only, as I understand
it the HTML equivalent goes into CSS.
3) Complex parameters. Like "generate.toc"


That said, here are the tasks that would be required:
- - reorganize parameters into sections that are more explicit to the end
user, perhaps inspired from word processing dialogs
- - refine the parameters categories
- - add further information to parameters for automatic processing
(parameter category, type of value, list of possible values, ...)
- - decide how to handle complex parameters to allow machine processing
(possibly by slicing into tinier pieces and then XSLT process to
generate the intended parameter complex value)
- - develop a proof of concept implementation.

To close this mail a few questions:

- - Is all this making sense at all?
- - Is this approach compatible with the XSLT2 ongoing work?
- - Should it be implemented, do stylesheet developers think it could be
integrated into current stylesheets distribution? Would you be willing
to maintain this system for future stylesheets modifications?

Thanks for reading, waiting to your comments.

Camille.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEn4yajv9P65BfOUMRAiyVAJ4hpW/ABQh9gmMu+8T6qdzcNDElugCgrUWa
F3EDKKIlTC2bFFHLdc3uGaI=
=dSDh
-----END PGP SIGNATURE-----
begin:vcard
fn;quoted-printable:Camille B=C3=A9gnis
n;quoted-printable:B=C3=A9gnis;Camille
org:NeoDoc
adr:Domaine du petit Arbois BP 88;;CEEI;Aix en Provence Cedex 4;;13545;France
email;internet:camille@neodoc.biz
tel;work:+33.4.42.22.62.35 
tel;cell:+33.6.33.15.10.23
note;quoted-printable:Rejoignez mon r=C3=A9seau sur viaduc:=0D=0A=
	=0D=0A=
	http://www.viaduc.com/invitationpersonnelle/002lm14bc0jlkfk
x-mozilla-html:FALSE
url:http://neodoc.biz
version:2.1
end:vcard



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