RE: [docbook-tc] questions on creating an assembly

["Rzedzicki, Lech" <Lech.Rzedzicki@uk.penguingroup.com>]

This is, I believe my first post on TC list, so let me introduce myselft
quickly.
I worked on XML Projects for Tech Writing, Law Publishing and now book
publishing in general for Motorola, Thomson Reuters and Penguin/DK
respectively. I am introducing more an more Docbook features in both
Penguin and Dorling-Kindersley and I think it's about time I started
participating more actively in the TC, if you're all right with that.
To start with, I have a couple of question about the naming conventions
and attributes vs elements in the assembly file.

-----Original Message-----
From: Bob Stayton [mailto:bobs@sagehill.net] 
Sent: 12 October 2009 23:06

1.  An output element cannot just have a renderas attribute, it must
also have an outputformat.  If one wants
the same renderas for all outputs, then outputformat must be set to
"ALL".  I'm wondering of outputformat could be optional, with the
meaning that if it is not present on an output element, then the output
element applies to all outputs.

I wonder, if attributes are used here, would it not be far more simple
to use those attributes straight on <module> elements?
I also have a more general comment about it - I'd love to see output
profiling survive chunking and assebly - so that it works whether it's
one file or many...

2.  I'm wondering if the indirection provided by a module element
pointing to a resource element which then points to a fileref is always
necessary. 
It seems the module element could accept fileref insted of resourceref
for those who don't want to separate their resources into a <resources>
element. 
For a simple book, requiring that extra level of indirection seems
intrusive. Did you consider that possibility?

Agreed, this should be optional but recommended. 
Furthermore, I have a general comment about element names - the
<resources> part is very much like a manifest file, so why not follow
that naming convention, for instance the ePub OPF one, which has
<manifest>/<item> documented quite nicely[1]
If a resource is defined in an <resource> element, I think it would also
be quite consistent to just call it from resourceref (or itemref for
item) rather than module?
I think otherwise it gets a little bit verbose.

3. A tiny bit, the topics/*.xml should have their RNC PI set to
../../rnc/topiccust.rnc rather than ../rnc/topiccust.rnc as it currently
is ;) For now I see this part is not taken care of in XSL, but it seems
easy enough.
 
Other than I am really glad to see this happening - getting benefits of
modular processing with benefits of well supported predefined vocabulary
of DocBook!

Lech Rzedzicki
Penguin Group UK

[1] http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html#Section2.3