Re: [docbook-apps] Storing data within Docbook?
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 anyName except nsName/ nsName ns=http://www.w3.org/1999/xhtml/ /except /anyName zeroOrMore choice ref name=db._any.attribute/ text/ ref name=db._any/ /choice /zeroOrMore /element /define You could store it in any namespace other than xhtml and convert it back when you use it downstream. Regards, David On 12/22/2013 07:14 PM, Vadim Peretokin wrote: 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 div xmlns=*http://www.w3.org/1999/xhtml-not-really*;!-- works -- p style=font-family: 'Lucida Sans'; text-align: leftThe document SHALL contain the individual's [...]./p /div /detail rationale *babbah*:div xmlns=http://www.omg.org/spec/ReqIF/20110401/reqif.xsd; xmlns:configuration=http://eclipse.org/rmf/pror/toolextensions/1.0; xmlns:headline=http://pror.org/presentation/headline; xmlns:rtf=http://pror.org/presentation/rtf;!-- works -- 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; xmlns:configuration=http://eclipse.org/rmf/pror/toolextensions/1.0; xmlns:headline=http://pror.org/presentation/headline; xmlns:rtf=http://pror.org/presentation/rtf;!-- does not work: E [Jing] element xhtml:div not allowed anywhere; expected the element end-tag or text -- xhtml:p style=font-family: 'Lucida Sans'; text-align: leftThe 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? - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Storing data within Docbook?
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 xmlns:vadim=http://somedomain-you-own/some-namespace-you-makeup;http://somedomain-you-own/some-namespace-you-makeup vadim:somefieldsomedata/vadim:somefield /vadim:metadata /info Ipsum lorem. Stuff readers see goes here. /para /td ... 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: tr td para info metadata xmlns=http://somedomain-you-own/some-namespace-you-makeup;http://somedomain-you-own/some-namespace-you-makeup somefieldsomedata/somefield /metadata /info Ipsum lorem. Stuff readers see goes here. /para /td 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 div xmlns=http://www.w3.org/1999/xhtml-not-really; !-- works -- p style=font-family: 'Lucida Sans'; text-align: leftThe document SHALL contain the individual's [...]./p /div /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 !-- works -- 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 !-- does not work: E [Jing] element xhtml:div not allowed anywhere; expected the element end-tag or text -- xhtml:p style=font-family: 'Lucida Sans'; text-align: leftThe 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.htmlhttp://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
Re: [docbook-apps] Storing data within Docbook?
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 additional data within it.' Thanks for elaborating, David. --Aaron On Tue, Nov 19, 2013 at 6:53 PM, David Cramer da...@thingbag.net 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 xmlns:vadim= http://somedomain-you-own/some-namespace-you-makeup; vadim:somefieldsomedata/vadim:somefield /vadim:metadata /info Ipsum lorem. Stuff readers see goes here. /para /td ... 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: tr td para info metadata xmlns= http://somedomain-you-own/some-namespace-you-makeup; somefieldsomedata/somefield /metadata /info Ipsum lorem. Stuff readers see goes here. /para /td 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). 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.pereto...@nehta.gov.au mailto: firstname.lastn...@nehta.gov.au Web: 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. - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org -- -- Aaron DaMommio: Husband, father, writer, juggler, and expert washer of dishes. - My blog: http://aarondamommio.blogspot.com - Need a juggler? http://amazingaaronjuggler.blogspot.com/ ===
Re: [docbook-apps] Storing data within Docbook?
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 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 additional data within it.' Thanks for elaborating, David. --Aaron On Tue, Nov 19, 2013 at 6:53 PM, David Cramer da...@thingbag.netmailto:da...@thingbag.net 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 xmlns:vadim=http://somedomain-you-own/some-namespace-you-makeup; vadim:somefieldsomedata/vadim:somefield /vadim:metadata /info Ipsum lorem. Stuff readers see goes here. /para /td ... 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: tr td para info metadata xmlns=http://somedomain-you-own/some-namespace-you-makeup; somefieldsomedata/somefield /metadata /info Ipsum lorem. Stuff readers see goes here. /para /td 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). 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.pereto...@nehta.gov.aumailto:vadim.pereto...@nehta.gov.au mailto:firstname.lastn...@nehta.gov.aumailto:firstname.lastn...@nehta.gov.au Web: www.nehta.gov.auhttp://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. - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.orgmailto:docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.orgmailto:docbook-apps-h...@lists.oasis-open.org -- -- Aaron DaMommio: Husband, father, writer, juggler, and expert washer of dishes. - My blog: http://aarondamommio.blogspot.com - Need a juggler? http://amazingaaronjuggler.blogspot.com/ === -- Vadim
Re: [docbook-apps] Storing data within Docbook?
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 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. I thought of adding extra columns in the Docbook table and setting them to be hidden - but it doesn't seem to be possible to 'hide' a column easily. Another idea would be to store in in XML comments - which would still be accessible in my transformation as well. *if* all your cells to be hidden are in the same column entry role='hidden' to contain the cells which you do not want to be shown? regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Storing data within Docbook?
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 -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz -- signature.asc Description: OpenPGP digital signature
Re: [docbook-apps] Storing data within Docbook?
-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 case (but you'll have to write your own tool or script to process the PI nodes). On 19/11/2013 14: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 - -- Fintan Bolton -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSi2zPAAoJEPmghGy20TDthLwH/3JfXiC1sCso6aGG7XLwj38K TMeBTUUE6keiM4Q01FBaOb0cIbkVeklZh6OFbSUwjd1Dfy8W2mVhzL+Ql62zFJLq iWGt8RHL9rKTRhxetti757C2pe9CJ4j8TUYc5PqCGntSKIWqxrcOVCbjIZTiI3et pO1VEc22V06uuhMyk2tN9ZXX0MSDV4CmLYDKXOT+6Hpkzk+emujfYghUi+57AK/w R8VnU3Ei9SBCP4SOGK9kl5jnXKA29FK+8eZIeaNXTY6BEqM0BMnnPbK4VIk+gMvL rjidSEg4P8O3SxyN3TfKqo0F/qKCVsXVPKibFbYJqbOCiMYTzod+CP7HXim0cbs= =Sl4t -END PGP SIGNATURE- - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Storing data within Docbook?
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 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.pereto...@nehta.gov.aumailto:firstname.lastn...@nehta.gov.au Web: www.nehta.gov.auhttp://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.
Fwd: Re: [docbook-apps] Storing data within Docbook?
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 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 case (but you'll have to write your own tool or script to process the PI nodes). On 19/11/2013 14: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 - -- Fintan Bolton -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSi2zPAAoJEPmghGy20TDthLwH/3JfXiC1sCso6aGG7XLwj38K TMeBTUUE6keiM4Q01FBaOb0cIbkVeklZh6OFbSUwjd1Dfy8W2mVhzL+Ql62zFJLq iWGt8RHL9rKTRhxetti757C2pe9CJ4j8TUYc5PqCGntSKIWqxrcOVCbjIZTiI3et pO1VEc22V06uuhMyk2tN9ZXX0MSDV4CmLYDKXOT+6Hpkzk+emujfYghUi+57AK/w R8VnU3Ei9SBCP4SOGK9kl5jnXKA29FK+8eZIeaNXTY6BEqM0BMnnPbK4VIk+gMvL rjidSEg4P8O3SxyN3TfKqo0F/qKCVsXVPKibFbYJqbOCiMYTzod+CP7HXim0cbs= =Sl4t -END PGP SIGNATURE- - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.orgmailto:docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.orgmailto:docbook-apps-h...@lists.oasis-open.org -- 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.pereto...@nehta.gov.aumailto:firstname.lastn...@nehta.gov.au Web: www.nehta.gov.auhttp://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.
Re: [docbook-apps] Storing data within Docbook?
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 xmlns:vadim=http://somedomain-you-own/some-namespace-you-makeup; vadim:somefieldsomedata/vadim:somefield /vadim:metadata /info Ipsum lorem. Stuff readers see goes here. /para /td ... 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: tr td para info metadata xmlns=http://somedomain-you-own/some-namespace-you-makeup; somefieldsomedata/somefield /metadata /info Ipsum lorem. Stuff readers see goes here. /para /td 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). 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.pereto...@nehta.gov.au mailto:firstname.lastn...@nehta.gov.au Web: 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. - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Storing data within Docbook?
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. Here's how it might look: ... tr td para info vadim:metadata xmlns:vadim=http://somedomain-you-own/some-namespace-you-makeup;http://somedomain-you-own/some-namespace-you-makeup vadim:somefieldsomedata/vadim:somefield /vadim:metadata /info Ipsum lorem. Stuff readers see goes here. /para /td ... 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: tr td para info metadata xmlns=http://somedomain-you-own/some-namespace-you-makeup;http://somedomain-you-own/some-namespace-you-makeup somefieldsomedata/somefield /metadata /info Ipsum lorem. Stuff readers see goes here. /para /td 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.htmlhttp://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.pereto...@nehta.gov.aumailto:vadim.pereto...@nehta.gov.au mailto:firstname.lastn...@nehta.gov.aumailto:firstname.lastn...@nehta.gov.au Web: www.nehta.gov.auhttp://www.nehta.gov.au http://www.nehta.gov.auhttp://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. -- 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.pereto...@nehta.gov.aumailto:firstname.lastn...@nehta.gov.au Web: www.nehta.gov.auhttp://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
Re: Fwd: Re: [docbook-apps] Storing data within Docbook?
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 the docbook stylesheets? stylesheet import docbook.xsl template match='db:entry[@role='ignore']/ Will 'pre-process' whilst importing and styling the xml as normal? That's (another good part of) the docbook stylesheets. HTH regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Storing data within Docbook?
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. I thought of adding extra columns in the Docbook table and setting them to be hidden - but it doesn't seem to be possible to 'hide' a column easily. Another idea would be to store in in XML comments - which would still be accessible in my transformation as well. What would be a good pattern to solve my use case? 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.
