You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(7) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(10) |
Feb
(17) |
Mar
(30) |
Apr
(9) |
May
(8) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(13) |
Oct
(1) |
Nov
(3) |
Dec
|
2008 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2009 |
Jan
(9) |
Feb
|
Mar
(4) |
Apr
(8) |
May
(1) |
Jun
(1) |
Jul
(9) |
Aug
(2) |
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
2010 |
Jan
(13) |
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
2011 |
Jan
(6) |
Feb
(1) |
Mar
(4) |
Apr
(7) |
May
(2) |
Jun
(12) |
Jul
(4) |
Aug
(7) |
Sep
(1) |
Oct
(5) |
Nov
(3) |
Dec
(4) |
2012 |
Jan
(4) |
Feb
(2) |
Mar
(4) |
Apr
(5) |
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(11) |
Dec
(2) |
2013 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2013-03-22 14:10:33
|
RFEs item #3608790, was opened at 2013-03-21 20:32 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3608790&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Wulf (jwulf) Assigned to: Nobody/Anonymous (nobody) Summary: Microdata or RDFa 1.1 Lite support for schema.org Initial Comment: Schema.org markup in HTML, embedded as Microdata or RDFa 1.1 Lite, is used by the major search engines to optimise discovery of relevant information. Schema.org has a proposed vocabulary for technical documentation: http://blog.schema.org/2012/06/newvocabularies-for-technical.html Using that vocabulary it's possible to, for example, mark up code samples with the product that they are relevant to, the product component, and the programming language. It looks like schema.org is converging on RDFa Lite: http://blog.schema.org/2011/11/using-rdfa-11-lite-with-schemaorg.html http://blog.schema.org/2012/06/semtech-rdfa-microdata-and-more.html Manu Sporny makes a solid case that RDFa Lite is the one to go with: http://manu.sporny.org/2012/mythical-differences/ This RFE is for Microdata or RDF 1.1 lite support in Docbook, so that we can use the Schema.org markup vocabularies in the HTML output from Docbook. ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2013-03-22 07:10 Message: Seems reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3608790&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-03-22 03:32:15
|
RFEs item #3608790, was opened at 2013-03-21 20:32 Message generated for change (Tracker Item Submitted) made by jwulf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3608790&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Wulf (jwulf) Assigned to: Nobody/Anonymous (nobody) Summary: Microdata or RDFa 1.1 Lite support for schema.org Initial Comment: Schema.org markup in HTML, embedded as Microdata or RDFa 1.1 Lite, is used by the major search engines to optimise discovery of relevant information. Schema.org has a proposed vocabulary for technical documentation: http://blog.schema.org/2012/06/newvocabularies-for-technical.html Using that vocabulary it's possible to, for example, mark up code samples with the product that they are relevant to, the product component, and the programming language. It looks like schema.org is converging on RDFa Lite: http://blog.schema.org/2011/11/using-rdfa-11-lite-with-schemaorg.html http://blog.schema.org/2012/06/semtech-rdfa-microdata-and-more.html Manu Sporny makes a solid case that RDFa Lite is the one to go with: http://manu.sporny.org/2012/mythical-differences/ This RFE is for Microdata or RDF 1.1 lite support in Docbook, so that we can use the Schema.org markup vocabularies in the HTML output from Docbook. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3608790&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-03-18 16:25:38
|
RFEs item #3491860, was opened at 2012-02-23 02:06 Message generated for change (Comment added) made by fsvensson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3491860&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fredrik Svensson (fsvensson) Assigned to: Norman Walsh (nwalsh) Summary: license tag Initial Comment: In June 2011 I did some work for including license information in a docbook article. http://lists.oasis-open.org/archives/docbook/201106/msg00013.html The proposal is presented here : http://article.tree.se/tools/docbook/cc.en.html and result is displayed here : http://article.tree.se/tools/docbook/cc.html There were no comments, indicating that the need was limited. Is there a better way to do this ? legalnotice is one way, but for "standard" licenses there could be an easier way. Maybe the suggested attributes belong to legalnotice instead of a new tag. Or is "standard" formatting for "standard" licenses out of the scope of docbook ? I did an attempt to use legalnotice in 2007 but it was not very successful. Perhaps a document with the normal creative commons look is just not feasible. I could try to improve the proposal if there is any interest, and if I get any indication to what needs to be changed. Thank you Fredrik ---------------------------------------------------------------------- >Comment By: Fredrik Svensson (fsvensson) Date: 2013-03-18 09:25 Message: 2007 I made this attempt with Legal notice : https://lists.oasis-open.org/archives/docbook-apps/200711/msg00061.html It was pretty verbose, and did not use any xsl for presentation. In retrospect that was probably the wrong way to get the Creative Commons look into a document. I was looking for a way to get the Creative commons look into some documents, in an easy way, and made the license tag suggestion. I was not sure how to extend the legalnotice. Maybe <legalnotice role="cc-by 3.0 us"/> then ? For me that would be fine as well, I do not need to create a new tag. I generate a documents with some images now that has CC license, and currently I do not have a good solution for the legal part. How would one write http://article.tree.se/tools/docbook/cc.en.xml in current Docbook ? I can try to adapt the http://article.tree.se/tools/docbook/cc.xsl for the same result. ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2013-02-20 10:46 Message: Can you explain how legalnotice failed to meet you needs? It seems to me that a legalnotice and a role attribute would be enough information for the stylesheet to generate the look you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3491860&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-02-20 18:46:04
|
RFEs item #3491860, was opened at 2012-02-23 02:06 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3491860&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fredrik Svensson (fsvensson) Assigned to: Norman Walsh (nwalsh) Summary: license tag Initial Comment: In June 2011 I did some work for including license information in a docbook article. http://lists.oasis-open.org/archives/docbook/201106/msg00013.html The proposal is presented here : http://article.tree.se/tools/docbook/cc.en.html and result is displayed here : http://article.tree.se/tools/docbook/cc.html There were no comments, indicating that the need was limited. Is there a better way to do this ? legalnotice is one way, but for "standard" licenses there could be an easier way. Maybe the suggested attributes belong to legalnotice instead of a new tag. Or is "standard" formatting for "standard" licenses out of the scope of docbook ? I did an attempt to use legalnotice in 2007 but it was not very successful. Perhaps a document with the normal creative commons look is just not feasible. I could try to improve the proposal if there is any interest, and if I get any indication to what needs to be changed. Thank you Fredrik ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2013-02-20 10:46 Message: Can you explain how legalnotice failed to meet you needs? It seems to me that a legalnotice and a role attribute would be enough information for the stylesheet to generate the look you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3491860&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-02-19 00:37:21
|
RFEs item #3531929, was opened at 2012-06-04 08:17 Message generated for change (Settings changed) made by bobstayton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531929&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Include Equivalent format Attribute Name to DocBook Elements Initial Comment: Hi, not only in the light of the new assembly mechanism, output formats are always a major topic for DocBook and the stylesheets. However, there is currently no standardized method to add an attribute specific for such a purpose. For simplicity reasons, I use "format" in this text. Feel free to use a different name like "outputformat", "targetformat", or whatever you think is appropriate. Actually, I don't care about the name, only about the idea. :) I know the committee is hesitant to add additional attributes to the schema, but I think it has several benefits. Here is why I think this is useful: 1. Currently, the DocBook stylesheets support several output formats. Probably this list will grow in the future. Dealing with such a variety of possible output formats makes it sometimes harder to write in a "format independant" way. However, if someone really wants to express that a certain element is only useful for PDF, the current list of common attributes doesn't support this. The user is forced to use a more general attribute like role or condition. From a semantic point of view, no common effectivity attributes are suited for this task. By using a "format" attribute in combination with profiling, I can distinguish such a case. 2. The current assembly schema contains in its <output/> element a "format" attribute (actually that's where this idea originated). However, with the raise of assemblies and modules, output formats will become much more important. From a usability point of view, having a consistent "format" attribute in DocBook and in <output/> does make sense: users can recognize that as the same "thing". 3. Adding a "format" attribute improves usability of children of mediaobject If you want several images but for different output formats, you need to use the role attribute in imagedata. This distinguish the high-resolution SVG for PDF from the low-resolution for HTML which is fine. However, from a usability point of view, the role attribute does a poor job on self-marketing. A "format" attribute would make it much more clear to the user what its purpose is. 4. Adding "only" an attribute to the DocBook schema is not as intrusive than adding a new element. :) The changes to the schema are minimal: db.format.attribute = ## Identifies the target format to which the element applies attribute format { text } db.effectivity.attributes = ... & db.format.attribute? Some might think, role or condition could be suitable. I don't think so, as role shouldn't be recommended for profiling and condition is the only general profiling attribute which is "freely" available to our users with no special semantic. Or in other words: it is occupied already by other meanings and shouldn't be (ab)used for output formats. As such, in my humble opinion, a "format" attribute should be added to the schema. The discussion can be followed on the mailinglist, see https://lists.oasis-open.org/archives/docbook/201206/msg00003.html ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 09:28 Message: The TC elected to add a new common effectivity attribute named 'outputformat' to address this RFE. Fixed in 5.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531929&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-02-19 00:36:41
|
RFEs item #3540409, was opened at 2012-07-05 02:47 Message generated for change (Settings changed) made by bobstayton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3540409&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Extending function Attribute for keycap Element Initial Comment: According to the TDG[1], keycap contains some values to markup "special" keys. For example, function="control" maps to the control key (written as "Ctrl" for an English keyboard[2]). However, there is no distinction between "Alt" (left alt key) and "Alt Gr" (right alt key). Furthermore, there is also no difference between "return" and "enter". Here are some reasons why I think the schema should be extended to support these values: * Consistency: It is much more consistent to write <keycap function="alt"/> or <keycap function="altgr"/> and rely on the DocBook stylesheets to do the right thing. * Language Support: Some keyboards could name the "Alt Gr" key differently than in English. * Translation: Translators doesn't have to know how to translate a key (although I would assume a translator e.g. from English to German would know the German key names, but I think, it safer to bother them with this minor details and improve consistency.) * Layout: "Exotic" keys can be mapped to a image during processing. * Validation: Having a list of possible values makes it easier to spot errors. I know, there is the “other” value in function and the otherfunction attribute to markup even more exotic keys. However, I think, the above distinction is such a basic thing that it should be included in DocBook. Maybe the committee thinks about adding this feature not only to DocBook v5.x but also to version 4.5. Thanks. ---- References [1] http://www.docbook.org/tdg5/en/html/keycap.html [2] http://en.wikipedia.org/wiki/File:Qwerty.svg ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 09:27 Message: Fixed for 5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3540409&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-02-19 00:35:55
|
RFEs item #3547943, was opened at 2012-07-24 08:38 Message generated for change (Settings changed) made by bobstayton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Shin ITANI (shinitani) Assigned to: Nobody/Anonymous (nobody) Summary: indexterm without primary Initial Comment: indexterm can have a secondary without a primary. Is this structure right? docbook.rnc (current): db.indexterm.contentmodel = db.primary?, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)? docbook.rnc (corrected); db.indexterm.contentmodel = (db.primary, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)?)? ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:55 Message: Good catch. Fixed in 5.1 ---------------------------------------------------------------------- Comment By: Shin ITANI (shinitani) Date: 2012-10-21 16:50 Message: Yes, I think so that. But, indexterm is allowed to have a secondary without a primary now. Could you fix it? ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-10-21 14:18 Message: Indexterm is not allowed to have a secondary without a primary. ---------------------------------------------------------------------- Comment By: Mauritz Jeanson (mzjn) Date: 2012-10-21 06:28 Message: Moving to RFEs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-02-19 00:35:02
|
RFEs item #3571149, was opened at 2012-09-24 02:31 Message generated for change (Settings changed) made by bobstayton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3571149&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Allow Article inside Set Initial Comment: Hi, according to the TDG[1], <set> allows another <set> or <book>, but no <article>. I would like to propose to include article as a possible child of <set> in the DocBook schema. Documentation for software products often contains not only Reference Manuals, but also Whitepapers and Quick Starts. The latter two are typically <article>s. In order to bundle the complete product documentation into a <set> to allow cross-linking, it currently is necessary to bundle the <article>s into a <book>. This is unfortunate, when a) only having one article that needs to be added, b) a number of articles covering not-related topics c) generating HTML/ePUB for the whole set (see TOC) For this reason, I think, an <article> would perfectly fit as a possible child of <set>. It avoids the need to create additional book structures just for the sake of being able to add articles to a set. Thanks! --- References: [1] http://www.docbook.org/tdg/en/html/set.html ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:11 Message: Fixed in 5.1 ---------------------------------------------------------------------- Comment By: Thomas Schraitle (tom_schr) Date: 2012-09-24 02:36 Message: The original discussion from the docbook mailinglist: https://lists.oasis-open.org/archives/docbook/201209/msg00005.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3571149&group_id=21935 |
From: SourceForge.net <no...@so...> - 2013-01-05 07:38:35
|
RFEs item #3599576, was opened at 2013-01-04 23:38 Message generated for change (Tracker Item Submitted) made by burbles You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3599576&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Gardiner (burbles) Assigned to: Norman Walsh (nwalsh) Summary: 'info' wrapper element for processing titlepage elements Initial Comment: Please consider adding a new element that is an immediate child or descendant of info, which allows within it all other descendants of info. The wrapper element could be assigned an attribute such as role="imprint" or role="titlepage", which helps to select all elements intended for a title page or imprint page. My use case would be to select all imprint page elements with one wrapper element, rather than adding a role attribute value to every element that I want to select. This selector element could potentially be used to make possible separate chunking of the imprint page and title page information, especially for EPUB and HTML output. Some publishers have a requirement to suppress imprint page information, or even place this at the back of an EPUB. That could only be achieved with customized chunking (possibly based on the templates for revhistory and legalnotice). A single selector element within info would make it easier to mark up elements for selection, and subsequent chunking customization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3599576&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-12-26 08:24:45
|
RFEs item #2933356, was opened at 2010-01-16 03:39 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=2933356&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook Group: v6.0 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Norman Walsh (nwalsh) Assigned to: Norman Walsh (nwalsh) Summary: Remove language attribute from address Initial Comment: The address element inherits the "language" attribute through the common verbatim attributes (continuation, linenumbering, startinglinenumber, language, and xml:space. I think that's probably a mistake. Language in the verbatim context is about programming languages. For a postal address, xml:lang is the only kind of language that applies, I think. ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-12-26 00:24 Message: Unmarked-fixed; backed out until V6.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=2933356&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-12-06 18:15:01
|
RFEs item #3593209, was opened at 2012-12-06 10:14 Message generated for change (Tracker Item Submitted) made by rlhamilton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3593209&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Hamilton (rlhamilton) Assigned to: Norman Walsh (nwalsh) Summary: Add see/seealso under Initial Comment: If you need to do a see or see also to a term that is a secondary term, indexers commonly use see under/see also under. It would be useful to allow an attribute for this purpose (possibly the class attribute, which is currently not used on see or seealso). The only impact on stylesheets would be to add gentext entries for see under and see also under and then add minimal code to the auto.idx stylesheet (I know stylesheets aren't covered here, so this is just to show that the implementation impact is minimal). If you used the class attribute, here is an usage example: <indexterm><primary>foo</primary><secondary>bar</secondary></indexterm> ... <indexterm><primary>bar</primary><seealso class="under">foo</seealso></indexterm> In this case, the seealso on bar points to the term foo, and says to look under foo for sub-headings named bar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3593209&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:55:16
|
RFEs item #3547943, was opened at 2012-07-24 08:38 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Shin ITANI (shinitani) Assigned to: Nobody/Anonymous (nobody) Summary: indexterm without primary Initial Comment: indexterm can have a secondary without a primary. Is this structure right? docbook.rnc (current): db.indexterm.contentmodel = db.primary?, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)? docbook.rnc (corrected); db.indexterm.contentmodel = (db.primary, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)?)? ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:55 Message: Good catch. Fixed in 5.1 ---------------------------------------------------------------------- Comment By: Shin ITANI (shinitani) Date: 2012-10-21 16:50 Message: Yes, I think so that. But, indexterm is allowed to have a secondary without a primary now. Could you fix it? ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-10-21 14:18 Message: Indexterm is not allowed to have a secondary without a primary. ---------------------------------------------------------------------- Comment By: Mauritz Jeanson (mzjn) Date: 2012-10-21 06:28 Message: Moving to RFEs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:28:57
|
RFEs item #3531365, was opened at 2012-06-01 09:07 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531365&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v5.1 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Stayton (bobstayton) Assigned to: Nobody/Anonymous (nobody) Summary: allow toc at beginning of section Initial Comment: In Docbook 4, the toc and other nav elements (glossary, bibliography, index) were allowed at both the beginning of sections and the end. In DocBook 5, they are allowed only at the end of section, sect1, etc. They are allowed in both locations in chapter, appendix, and preface, as well as topic. Certainly the toc element at least should be allowed at the beginning of sections. This change would be backwards compatible since it loosens the content model. ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:28 Message: Simple oversight. Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531365&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:20:36
|
RFEs item #3530659, was opened at 2012-05-29 13:48 Message generated for change (Settings changed) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3530659&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.0 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Bill Burns (wdburns) Assigned to: Norman Walsh (nwalsh) Summary: Schematron constraints for table Initial Comment: Currently, the Schematron rules for DB 5.0 constrain the use of admonitions (caution, note, tip, etc) as descendants of table. Aside from the impracticality of this constraint for technical writers (who frequently use admonitions in tables cells), this rule seems to cause inconsistent validation in some tools (for example, Oxygen 13.2, which sometimes flags the condition and sometimes doesn't). See lines 216-226 in docbook.sch. ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:13 Message: Restriction against admonitions in formal objects (tables, figures, examples) removed in 5.1 ---------------------------------------------------------------------- Comment By: David Cramer (dcramer) Date: 2012-05-29 14:12 Message: +1 I've always wondered why that one is in there (and have removed it from our local oxygen framework). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3530659&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:20:32
|
RFEs item #3531929, was opened at 2012-06-04 08:17 Message generated for change (Settings changed) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531929&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Include Equivalent format Attribute Name to DocBook Elements Initial Comment: Hi, not only in the light of the new assembly mechanism, output formats are always a major topic for DocBook and the stylesheets. However, there is currently no standardized method to add an attribute specific for such a purpose. For simplicity reasons, I use "format" in this text. Feel free to use a different name like "outputformat", "targetformat", or whatever you think is appropriate. Actually, I don't care about the name, only about the idea. :) I know the committee is hesitant to add additional attributes to the schema, but I think it has several benefits. Here is why I think this is useful: 1. Currently, the DocBook stylesheets support several output formats. Probably this list will grow in the future. Dealing with such a variety of possible output formats makes it sometimes harder to write in a "format independant" way. However, if someone really wants to express that a certain element is only useful for PDF, the current list of common attributes doesn't support this. The user is forced to use a more general attribute like role or condition. From a semantic point of view, no common effectivity attributes are suited for this task. By using a "format" attribute in combination with profiling, I can distinguish such a case. 2. The current assembly schema contains in its <output/> element a "format" attribute (actually that's where this idea originated). However, with the raise of assemblies and modules, output formats will become much more important. From a usability point of view, having a consistent "format" attribute in DocBook and in <output/> does make sense: users can recognize that as the same "thing". 3. Adding a "format" attribute improves usability of children of mediaobject If you want several images but for different output formats, you need to use the role attribute in imagedata. This distinguish the high-resolution SVG for PDF from the low-resolution for HTML which is fine. However, from a usability point of view, the role attribute does a poor job on self-marketing. A "format" attribute would make it much more clear to the user what its purpose is. 4. Adding "only" an attribute to the DocBook schema is not as intrusive than adding a new element. :) The changes to the schema are minimal: db.format.attribute = ## Identifies the target format to which the element applies attribute format { text } db.effectivity.attributes = ... & db.format.attribute? Some might think, role or condition could be suitable. I don't think so, as role shouldn't be recommended for profiling and condition is the only general profiling attribute which is "freely" available to our users with no special semantic. Or in other words: it is occupied already by other meanings and shouldn't be (ab)used for output formats. As such, in my humble opinion, a "format" attribute should be added to the schema. The discussion can be followed on the mailinglist, see https://lists.oasis-open.org/archives/docbook/201206/msg00003.html ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 09:28 Message: The TC elected to add a new common effectivity attribute named 'outputformat' to address this RFE. Fixed in 5.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531929&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:20:26
|
RFEs item #3540409, was opened at 2012-07-05 02:47 Message generated for change (Settings changed) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3540409&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Extending function Attribute for keycap Element Initial Comment: According to the TDG[1], keycap contains some values to markup "special" keys. For example, function="control" maps to the control key (written as "Ctrl" for an English keyboard[2]). However, there is no distinction between "Alt" (left alt key) and "Alt Gr" (right alt key). Furthermore, there is also no difference between "return" and "enter". Here are some reasons why I think the schema should be extended to support these values: * Consistency: It is much more consistent to write <keycap function="alt"/> or <keycap function="altgr"/> and rely on the DocBook stylesheets to do the right thing. * Language Support: Some keyboards could name the "Alt Gr" key differently than in English. * Translation: Translators doesn't have to know how to translate a key (although I would assume a translator e.g. from English to German would know the German key names, but I think, it safer to bother them with this minor details and improve consistency.) * Layout: "Exotic" keys can be mapped to a image during processing. * Validation: Having a list of possible values makes it easier to spot errors. I know, there is the “other” value in function and the otherfunction attribute to markup even more exotic keys. However, I think, the above distinction is such a basic thing that it should be included in DocBook. Maybe the committee thinks about adding this feature not only to DocBook v5.x but also to version 4.5. Thanks. ---- References [1] http://www.docbook.org/tdg5/en/html/keycap.html [2] http://en.wikipedia.org/wiki/File:Qwerty.svg ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 09:27 Message: Fixed for 5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3540409&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:20:24
|
RFEs item #3571149, was opened at 2012-09-24 02:31 Message generated for change (Settings changed) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3571149&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Allow Article inside Set Initial Comment: Hi, according to the TDG[1], <set> allows another <set> or <book>, but no <article>. I would like to propose to include article as a possible child of <set> in the DocBook schema. Documentation for software products often contains not only Reference Manuals, but also Whitepapers and Quick Starts. The latter two are typically <article>s. In order to bundle the complete product documentation into a <set> to allow cross-linking, it currently is necessary to bundle the <article>s into a <book>. This is unfortunate, when a) only having one article that needs to be added, b) a number of articles covering not-related topics c) generating HTML/ePUB for the whole set (see TOC) For this reason, I think, an <article> would perfectly fit as a possible child of <set>. It avoids the need to create additional book structures just for the sake of being able to add articles to a set. Thanks! --- References: [1] http://www.docbook.org/tdg/en/html/set.html ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:11 Message: Fixed in 5.1 ---------------------------------------------------------------------- Comment By: Thomas Schraitle (tom_schr) Date: 2012-09-24 02:36 Message: The original discussion from the docbook mailinglist: https://lists.oasis-open.org/archives/docbook/201209/msg00005.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3571149&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:19:56
|
RFEs item #3517981, was opened at 2012-04-14 23:46 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3517981&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v5.1 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian M. Ames (bmames) Assigned to: Nobody/Anonymous (nobody) Summary: Ambiguous attribute definition Initial Comment: The definition of the class attribute for the othercredit element in versions 5.0 and 5.1 is ambiguous because the enumeration contains "other" twice, once without a required otherclass attribute and once with. ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:19 Message: Fixed in 5.1 ---------------------------------------------------------------------- Comment By: Mauritz Jeanson (mzjn) Date: 2012-10-14 02:21 Message: Moved to RFEs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3517981&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:13:12
|
RFEs item #3530659, was opened at 2012-05-29 13:48 Message generated for change (Settings changed) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3530659&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.0 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Bill Burns (wdburns) Assigned to: Norman Walsh (nwalsh) Summary: Schematron constraints for table Initial Comment: Currently, the Schematron rules for DB 5.0 constrain the use of admonitions (caution, note, tip, etc) as descendants of table. Aside from the impracticality of this constraint for technical writers (who frequently use admonitions in tables cells), this rule seems to cause inconsistent validation in some tools (for example, Oxygen 13.2, which sometimes flags the condition and sometimes doesn't). See lines 216-226 in docbook.sch. ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:13 Message: Restriction against admonitions in formal objects (tables, figures, examples) removed in 5.1 ---------------------------------------------------------------------- Comment By: David Cramer (dcramer) Date: 2012-05-29 14:12 Message: +1 I've always wondered why that one is in there (and have removed it from our local oxygen framework). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3530659&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 19:11:28
|
RFEs item #3571149, was opened at 2012-09-24 02:31 Message generated for change (Settings changed) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3571149&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Allow Article inside Set Initial Comment: Hi, according to the TDG[1], <set> allows another <set> or <book>, but no <article>. I would like to propose to include article as a possible child of <set> in the DocBook schema. Documentation for software products often contains not only Reference Manuals, but also Whitepapers and Quick Starts. The latter two are typically <article>s. In order to bundle the complete product documentation into a <set> to allow cross-linking, it currently is necessary to bundle the <article>s into a <book>. This is unfortunate, when a) only having one article that needs to be added, b) a number of articles covering not-related topics c) generating HTML/ePUB for the whole set (see TOC) For this reason, I think, an <article> would perfectly fit as a possible child of <set>. It avoids the need to create additional book structures just for the sake of being able to add articles to a set. Thanks! --- References: [1] http://www.docbook.org/tdg/en/html/set.html ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 11:11 Message: Fixed in 5.1 ---------------------------------------------------------------------- Comment By: Thomas Schraitle (tom_schr) Date: 2012-09-24 02:36 Message: The original discussion from the docbook mailinglist: https://lists.oasis-open.org/archives/docbook/201209/msg00005.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3571149&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 17:28:02
|
RFEs item #3531929, was opened at 2012-06-04 08:17 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531929&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Include Equivalent format Attribute Name to DocBook Elements Initial Comment: Hi, not only in the light of the new assembly mechanism, output formats are always a major topic for DocBook and the stylesheets. However, there is currently no standardized method to add an attribute specific for such a purpose. For simplicity reasons, I use "format" in this text. Feel free to use a different name like "outputformat", "targetformat", or whatever you think is appropriate. Actually, I don't care about the name, only about the idea. :) I know the committee is hesitant to add additional attributes to the schema, but I think it has several benefits. Here is why I think this is useful: 1. Currently, the DocBook stylesheets support several output formats. Probably this list will grow in the future. Dealing with such a variety of possible output formats makes it sometimes harder to write in a "format independant" way. However, if someone really wants to express that a certain element is only useful for PDF, the current list of common attributes doesn't support this. The user is forced to use a more general attribute like role or condition. From a semantic point of view, no common effectivity attributes are suited for this task. By using a "format" attribute in combination with profiling, I can distinguish such a case. 2. The current assembly schema contains in its <output/> element a "format" attribute (actually that's where this idea originated). However, with the raise of assemblies and modules, output formats will become much more important. From a usability point of view, having a consistent "format" attribute in DocBook and in <output/> does make sense: users can recognize that as the same "thing". 3. Adding a "format" attribute improves usability of children of mediaobject If you want several images but for different output formats, you need to use the role attribute in imagedata. This distinguish the high-resolution SVG for PDF from the low-resolution for HTML which is fine. However, from a usability point of view, the role attribute does a poor job on self-marketing. A "format" attribute would make it much more clear to the user what its purpose is. 4. Adding "only" an attribute to the DocBook schema is not as intrusive than adding a new element. :) The changes to the schema are minimal: db.format.attribute = ## Identifies the target format to which the element applies attribute format { text } db.effectivity.attributes = ... & db.format.attribute? Some might think, role or condition could be suitable. I don't think so, as role shouldn't be recommended for profiling and condition is the only general profiling attribute which is "freely" available to our users with no special semantic. Or in other words: it is occupied already by other meanings and shouldn't be (ab)used for output formats. As such, in my humble opinion, a "format" attribute should be added to the schema. The discussion can be followed on the mailinglist, see https://lists.oasis-open.org/archives/docbook/201206/msg00003.html ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 09:28 Message: The TC elected to add a new common effectivity attribute named 'outputformat' to address this RFE. Fixed in 5.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3531929&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-11-14 17:27:09
|
RFEs item #3540409, was opened at 2012-07-05 02:47 Message generated for change (Settings changed) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3540409&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Schraitle (tom_schr) Assigned to: Norman Walsh (nwalsh) Summary: Extending function Attribute for keycap Element Initial Comment: According to the TDG[1], keycap contains some values to markup "special" keys. For example, function="control" maps to the control key (written as "Ctrl" for an English keyboard[2]). However, there is no distinction between "Alt" (left alt key) and "Alt Gr" (right alt key). Furthermore, there is also no difference between "return" and "enter". Here are some reasons why I think the schema should be extended to support these values: * Consistency: It is much more consistent to write <keycap function="alt"/> or <keycap function="altgr"/> and rely on the DocBook stylesheets to do the right thing. * Language Support: Some keyboards could name the "Alt Gr" key differently than in English. * Translation: Translators doesn't have to know how to translate a key (although I would assume a translator e.g. from English to German would know the German key names, but I think, it safer to bother them with this minor details and improve consistency.) * Layout: "Exotic" keys can be mapped to a image during processing. * Validation: Having a list of possible values makes it easier to spot errors. I know, there is the “other” value in function and the otherfunction attribute to markup even more exotic keys. However, I think, the above distinction is such a basic thing that it should be included in DocBook. Maybe the committee thinks about adding this feature not only to DocBook v5.x but also to version 4.5. Thanks. ---- References [1] http://www.docbook.org/tdg5/en/html/keycap.html [2] http://en.wikipedia.org/wiki/File:Qwerty.svg ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-11-14 09:27 Message: Fixed for 5.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3540409&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-10-21 23:50:56
|
RFEs item #3547943, was opened at 2012-07-24 08:38 Message generated for change (Comment added) made by shinitani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shin ITANI (shinitani) Assigned to: Nobody/Anonymous (nobody) Summary: indexterm without primary Initial Comment: indexterm can have a secondary without a primary. Is this structure right? docbook.rnc (current): db.indexterm.contentmodel = db.primary?, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)? docbook.rnc (corrected); db.indexterm.contentmodel = (db.primary, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)?)? ---------------------------------------------------------------------- >Comment By: Shin ITANI (shinitani) Date: 2012-10-21 16:50 Message: Yes, I think so that. But, indexterm is allowed to have a secondary without a primary now. Could you fix it? ---------------------------------------------------------------------- Comment By: Norman Walsh (nwalsh) Date: 2012-10-21 14:18 Message: Indexterm is not allowed to have a secondary without a primary. ---------------------------------------------------------------------- Comment By: Mauritz Jeanson (mzjn) Date: 2012-10-21 06:28 Message: Moving to RFEs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-10-21 21:18:58
|
RFEs item #3547943, was opened at 2012-07-24 08:38 Message generated for change (Comment added) made by nwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DocBook XML Group: v5.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shin ITANI (shinitani) Assigned to: Nobody/Anonymous (nobody) Summary: indexterm without primary Initial Comment: indexterm can have a secondary without a primary. Is this structure right? docbook.rnc (current): db.indexterm.contentmodel = db.primary?, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)? docbook.rnc (corrected); db.indexterm.contentmodel = (db.primary, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)?)? ---------------------------------------------------------------------- >Comment By: Norman Walsh (nwalsh) Date: 2012-10-21 14:18 Message: Indexterm is not allowed to have a secondary without a primary. ---------------------------------------------------------------------- Comment By: Mauritz Jeanson (mzjn) Date: 2012-10-21 06:28 Message: Moving to RFEs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 |
From: SourceForge.net <no...@so...> - 2012-10-21 13:28:35
|
RFEs item #3547943, was opened at 2012-07-24 08:38 Message generated for change (Comment added) made by mzjn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: DocBook XML >Group: v5.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shin ITANI (shinitani) Assigned to: Nobody/Anonymous (nobody) Summary: indexterm without primary Initial Comment: indexterm can have a secondary without a primary. Is this structure right? docbook.rnc (current): db.indexterm.contentmodel = db.primary?, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)? docbook.rnc (corrected); db.indexterm.contentmodel = (db.primary, ((db.secondary, ((db.tertiary, (db.see | db.seealso+)?) | db.see | db.seealso+)?) | db.see | db.seealso+)?)? ---------------------------------------------------------------------- >Comment By: Mauritz Jeanson (mzjn) Date: 2012-10-21 06:28 Message: Moving to RFEs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384107&aid=3547943&group_id=21935 |