On 07/22/2009 09:14 AM, Jirka Kosek wrote:
Dave Pawson wrote:
> Jirka, how does this idea fit with 'extending' docbook, vs incorporation
> via a namespace vs incorporating into docbook processing?
There are many possibilities, depends on your usage scenario, for example.
1) Incorporate graph2svg markup directly into DocBook
2) Keep graph2svg markup in separate files, turn them into SVG by
external process and then include them as figures on DocBook level
3) Do some more advanced things, like have a DocBook table with special
role assigned and then tweak stylesheets to generate graph2svg markup
from DocBook table, then use graph2svg stylesheet to get SVG from this
and include this resulting SVG into FO/XHTML generated by DocBook
stylesheets, everything in single transformation
But be careful when integrating graph2svg into DocBook stylesheets.
Library requires XSLT 2.0, so you have to use Saxon9 and some things are
still not working in Saxon9 (for example chunking, but there is partial
patch for this scheduled for 1.76.0 sitting on my filesystem).
Ah! The killer! Yes, it's XSLT 2.0
Immediate reaction, I would prefer the 'graph' markup to using a
standard table. There are too many differences between the graph
and a docbook table. It would look like a kludge.
So for the short term, process the graph outside docbook,
then include the resulting file as 'normal' within docbook.
In the long term, I like Chris's idea.
Consider it 'another namespace' content and process it
as ... an extension? But that will have to wait until
the XSLT 2.0 docbook stylesheets I guess.
Have any principles been worked out for doing this more generally?
I've not heard anything. E.g. I want to incorporate xmlns="xxxx"
what should I do for validation and processing? More NVDL I guess.
btw Jirka, the namespace isn't declared in the DTD,
on the root element?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
