Looking at docbook.rng, I see that the xhtml namespace is explicitly
excluded. I don't know why they schema is written that way; perhaps
someone else can explain the rational:
define name=db._any
element
a:documentationAny element from almost any
namespace/a:documentation
On 20/11/13 10:53, David Cramer wrote:
Jirka's suggestion is the best approach. It gives you all the flexiblity
in the world with no extra work. Here's how it might look:
...
tr
td
para
info
vadim:metadata
Oh, wow, I didn't understand at first from what Jirka said, that the idea
here was to put the full original xml data embedded in the info element,
for downstream use. That's a neat trick. I was still thinking along the
lines of 'I want to convert my source xml to some docbook format but hide
some
It is that same approach though, 'I want to convert my source xml to some
docbook format but hide some additional data within it.'.
On 21/11/13 03:05, Aaron DaMommio wrote:
Oh, wow, I didn't understand at first from what Jirka said, that the idea here
was to put the full original xml data
On 19/11/13 00:34, Vadim Peretokin wrote:
I'm transforming some data from an XML format into a Docbook table - but
not all of the data in the XML is to be displayed in Docbook. I would,
however, like to store it in my Docbook XML - because future
transformations would like to read my Docbook XML
On 19.11.2013 1:34, Vadim Peretokin wrote:
I'm transforming some data from an XML format into a Docbook table - but not
all of the data in the XML is to be displayed in Docbook. I would, however,
like to store it in my Docbook XML - because future transformations would
like to read my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Also you could consider using Processing Instructions (PI), which have
the following syntax:
?MyProcessorName Anything you like in here ?
This is a general-purpose mechanism for embedding metadata in an XML
file. Sounds like it might be useful in
This sounds really interesting and viable, the second being the profiling of
the role attribute (which I'd like to avoid if I can due to good advice given
herehttp://www.sagehill.net/docbookxsl/ProfilingWithRole.html). However it
seems the schema doesn't allow adding other elements, even from
Dodgy mailing list software on some servers broke my habit of 'reply all'.
Sorry - forwarding to the ML.
I wouldn't want to be creating niche tools just to deal with this relatively
small project.
On 19/11/13 23:52, Fintan Bolton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Also
Jirka's suggestion is the best approach. It gives you all the flexiblity
in the world with no extra work. Here's how it might look:
...
tr
td
para
info
vadim:metadata
Brilliant - thanks, I'll go with the first approach. It seems to be most
compatible, causes least headaches and easiest to work with in an XSLT.
On 20/11/13 10:53, David Cramer wrote:
Jirka's suggestion is the best approach. It gives you all the flexiblity
in the world with no extra work.
On 20/11/13 00:38, Vadim Peretokin wrote:
Dodgy mailing list software on some servers broke my habit of 'reply
all'. Sorry - forwarding to the ML.
Alright - I'll have to make my custom Docbook stylesheet ignore this
entry then though when preprocessing it, right?
Yes... No.
Customize
I'm transforming some data from an XML format into a Docbook table - but not
all of the data in the XML is to be displayed in Docbook. I would, however,
like to store it in my Docbook XML - because future transformations would like
to read my Docbook XML and they'd need all of the data that
13 matches
Mail list logo
