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:
...
<para>
<info>
<vadim:metadata xmlns:vadim="http://somedomain-you-own/some-namespace-you-makeup"<http://somedomain-you-own/some-namespace-you-makeup>>
<vadim:somefield>somedata</vadim:somefield>
</vadim:metadata>
</info>
Ipsum lorem. Stuff readers see goes here.
</para>
...
DocBook's info element and its contents are already ignored by the xslts.
You can encode your data in xml as complex as it needs to be in a namespace
of your invention. Here's another way of doing it if you don't like namespace prefixes:
<para>
<info>
<metadata xmlns="http://somedomain-you-own/some-namespace-you-makeup"<http://somedomain-you-own/some-namespace-you-makeup>>
<somefield>somedata</somefield>
</metadata>
</info>
Ipsum lorem. Stuff readers see goes here.
</para>
I'm having difficulty embedding elements of the XHTML namespace within my metadata. It seems that with either of the approaches above, I cannot use the elements in the XHTML namespace - but any other namespace works. Quite strange. Here's an annotated snippet:
<informaltable>
<info>
[...]
<requirement name="Person identifier"
number="[...]"
ea-id="[...]">
<detail>
The document SHALL contain the individual's [...].
</detail>
<rationale>
<babbah:div xmlns="http://www.omg.org/spec/ReqIF/20110401/reqif.xsd"<http://www.omg.org/spec/ReqIF/20110401/reqif.xsd>
xmlns:configuration="http://eclipse.org/rmf/pror/toolextensions/1.0"<http://eclipse.org/rmf/pror/toolextensions/1.0>
xmlns:headline="http://pror.org/presentation/headline"<http://pror.org/presentation/headline>
xmlns:rtf="http://pror.org/presentation/rtf"<http://pror.org/presentation/rtf>>
<babbah:div style="text-align: left;">Allows interoperability. Eliminates ambiguity. [...]</babbah:div>
</babbah:div>
</rationale>
</requirement>
<requirement name="Person name"
number="[...]"
ea-id="[...]">
<detail>
<xhtml:div xmlns="http://www.omg.org/spec/ReqIF/20110401/reqif.xsd"<http://www.omg.org/spec/ReqIF/20110401/reqif.xsd>
xmlns:configuration="http://eclipse.org/rmf/pror/toolextensions/1.0"<http://eclipse.org/rmf/pror/toolextensions/1.0>
xmlns:headline="http://pror.org/presentation/headline"<http://pror.org/presentation/headline>
xmlns:rtf="http://pror.org/presentation/rtf"<http://pror.org/presentation/rtf>>
<xhtml:p style="font-family: 'Lucida Sans'; text-align: left">The document SHALL contain the given (where applicable) and family name of the person the document relates to.</xhtml:p>
</xhtml:div>
</detail>
Why would the DocBook 5 (http://docbook.org/ns/docbook) schema be disallowing xhtml specifically and/or what is the error?
Regards,
David
On 11/19/2013 06:36 PM, Vadim Peretokin wrote:
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 here
<http://www.sagehill.net/docbookxsl/ProfilingWithRole.html><http://www.sagehill.net/docbookxsl/ProfilingWithRole.html>). However it
seems the schema doesn't allow adding other elements, even from other
namespaces? Adding an an <extradata:info> to a <row> (the ideal
situation; easiest to deal with then when working with XSLT on it!)
gives a validation error: E [Jing] element "extradata:info" not allowed
here; expected element "entry" or "entrytbl"
On 19/11/13 23:19, Jirka Kosek wrote:
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 Docbook XML and they'd need all of the data that went into it. I'd rather not introduce a secondary file for storing the extra data - this would bring complications and fragility.
The easiest way to do this is to add <info> element to the table and put
you raw XML data there -- they just must be in different namespace then
DocBook in order to validate.
Jirka
--
Vadim Peretokin
Clinical Information Modeller
*nehta - National E-Health Transition Authority*
Level 2, 10 Browning St, West End, QLD 4101, Australia
Phone: (0) 3023 8573
Email:
vadim.peretokin@nehta.gov.au<mailto:
vadim.peretokin@nehta.gov.au> <mailto:
firstname.lastname@nehta.gov.au><mailto:
firstname.lastname@nehta.gov.au>
Web:
www.nehta.gov.au<http://www.nehta.gov.au> <http://www.nehta.gov.au><http://www.nehta.gov.au>
The information contained in this e-mail message and any accompanying
files is or may be privileged or confidential. If you are not the
intended recipient, any use, dissemination, reliance, forwarding,
printing or copying of this e-mail or any attached files is
unauthorised. This e-mail and any attachments may be subject to
copyright. Copyright material should not be reproduced, adapted or
communicated without the written consent of the copyright owner. If you
have received this e-mail in error please advise the sender immediately
by return e-mail or telephone and delete all copies. NEHTA does not make
any representations or give any guarantees in respect of the accuracy or
completeness of any information contained in this e-mail or attached
files. Internet communications are not secure, therefore NEHTA does not
accept any liability for the contents of this message or attached files.
The information contained in this e-mail message and any accompanying files is or may be privileged or confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail and any attachments may be subject to copyright. Copyright material should not be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. NEHTA does not make any representations or give any guarantees in respect of the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore NEHTA does not accept any liability for the contents of this message or attached files.