OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: summary of discussions on mew publications map design


I looked over the minutes from March 14 & 21, and gleaned the following:  I'm including links to all the emails that preceded and informed those discussions, as well as to the minutes themselves, in case any of you are gluttons for punishment :-).


High points of discussions around new publication map, March 14 & 21:
- high-level; we want to break apart bookmap design to create a publication map with separate domains; probably a map domain, topic domain, metadata domain (a la Eliot's d4p pubmap, but probably not as complex)
- metadata domain to include current bookmap metadata, but also add missing items  e.g. ISS, non-copyright (as in 'creative commons') license, etc.
- optional frontmatter and backmatter
- allow certain specializations of topicref - keys and ditavalref in particular -  at root level, possibly in its own container  (this would allow for the addition of keyrefs in critical places where they're currently missing)
- standardized ditavalref usage (possibly as first optional child after a map?)
- should we keep xnal domain, or shrink it, add parts of it to a new pubmeta domain??
- specialized submap types to define things like chaptermap and partmap
- should bookmap topic types go into their own domain, so they can be included in new publication map without having to use 1.3 'structural domain' feature?
- ability to reference one pubmap from within another pubmap (can't reference one bookmap from within another)
- allow more flexibility in ordering map elements; currently, can't have a chapter before a part.
- provision for cover pages and logos
- new pub map would be part of base DITA, vs current bookmap in tech-content
- do we need to consider publishing considerations, e.g. changes to xref to allow for more control over xref styles?
- address glossary issues; move to its own domain usable in a standard way from any map (glossaryref type as replacement for glossarylist?)
- possible names for new map: pubmap, docmap, bookmap2, ??

minutes, March 14:

https://lists.oasis-open.org/archives/dita/201703/msg00020.html (Nancy Harrison, posted 14 March 2017)

pre-March 14 email links:
New item: Overall fixes for bookmap for DITA 2.0

https://lists.oasis-open.org/archives/dita/201702/msg00033.html (Eric Sirois, 21 February 2017)

https://lists.oasis-open.org/archives/dita/201702/msg00035.html (Eric Sirois, 21 February 2017)

https://lists.oasis-open.org/archives/dita/201702/msg00038.html (Kimber, 21 February 2017)

https://lists.oasis-open.org/archives/dita/201702/msg00040.html (Nitchie, 21 February 2017)

https://lists.oasis-open.org/archives/dita/201702/msg00048.html (Swope, 21 February 2017)

https://lists.oasis-open.org/archives/dita/201702/msg00050.html (Eberlein, 21 February 2017)

https://lists.oasis-open.org/archives/dita/201702/msg00051.html (Kimber, 21 February 2017)

minutes, March 21
https://lists.oasis-open.org/archives/dita/201703/msg00025.html (Nancy Harrison, posted 21 March 2017)

pre-March 21 email links:
Continuing item: Overall fixes for bookmap for DITA 2.0

Additional bookmap-related work:
During the March 14 & 21 calls, we also discussed fixes to bookmap.  I'm including a summary of those conversations, as well as a later one on May 23rd, just as reference here, given that our creation of a new publications map will most likely impact, and possibly be impacted by, that work.

Fixes proposed to bookmap during March 14 & 21 calls
- make bookmatter options
- suggestion to break bookmap into domains, but that would break it entirely...
- loosen bookmap constraints
- include ways to set keyrefs and ditavalrefs at top level
- glossaryref type as replacement for glossarylist?

May 23:
8.  Changes to Bookmap for DITA 2.0
Discussions after Chris's high-level design proposal for fixes to bookmap in 2.0:
1. Summary of email discussion between Chris & Eliot (emails above): The proposal was basically to allow general topicrefs at the root level of bookmap; not having those makes it impossible to use ditavalref. The other part is related; allow topicref and its specializations before frontmatter. Eliot presented concerns, specifically that allowing any topicref (and its specializations) there would undo all kinds of constraints. OTOH, we can special case that just ditavalref could go there, but still... Eliot also suggested we have a new container for keydefs, suggestion that we create it as a domain spec, then we could use it for both a new publications map and for a modified bookmap.
2. at TC meeting
- general consensus is that we don't want to allow topicref at beginning of bookmap, but we do want a limited solution that would facilitate using ditavalref and keys.
- work will be done under TechContent SC, owner Eric

Nancy Harrison
Infobridge Solutions 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]