Re: [dita] Changes to Bookmap for DITA 2.0

[Chris Nitchie <chris.nitchie@oberontech.com>]

My primary concern is allowing <ditavalref> before <frontmatter>. We could make a special exception for <ditavalref>, but that would preclude any other custom map-level processing configured by ‘first-child’ topicref specializations.

Chris

On 5/22/17, 1:26 PM, "dita@lists.oasis-open.org on behalf of Eliot Kimber" <dita@lists.oasis-open.org on behalf of ekimber@contrext.com> wrote:

    Ah, I forgot we had decided on a separate Bookmap 2.0. 
    
    I still have the basic concern about allowing any specialization of topicref before <frontmatter> in 1.x Bookmap. Adding a wrapper would be backward compatible (in that it wouldn’t invalidate any existing bookmaps).
    
    Such a wrapper could be a separate domain so that it’s available to both 1.x Bookmap and any new map types. It could be a very simple domain.
    
    Cheers,
    
    E.
    
    --
    Eliot Kimber
    http://contrext.com
     
    
    
    On 5/22/17, 12:14 PM, "Chris Nitchie" <chris.nitchie@oberontech.com> wrote:
    
        I think we’re talking abot different things. If I recall correctly, there are two separate initiatives in the 2.0 timeframe.
        
        - Loosen up BookMap to alleviate some of the limitations caused by the rigidity of its structure.
        - Create ‘BookMap 2.0’ (final name TBD) along some of the lines you’re talking about here.
        
        I’m attempting to address the former. The latter will be much bigger.
        
        Chris
        
        On 5/22/17, 1:12 PM, "Eliot Kimber" <ekimber@contrext.com> wrote:
        
            By “backward compatible” do you mean tagname compatible or specialization hierarchy compatible?
            
            Hopefully you mean the tagname compatible. 
            
            If we commit to tagname compatible it would still allow us to refactor bookmap into a system of domains plus a much-smaller map type.
            
            For keydefs, I would prefer to add a new keydef-containing element rather than simply allowing any specialization of topicref, as that would have the effect of undoing any content model constraints.
            
            E.g, a new element <keydefs>, specialized from topicgroup, that sets processing-role to “resource-only” and then itself allows any specialization of topicref.
            
            It would occur before <frontmatter> in the current Bookmap model.
            
            I have more ideas for improvement but I’ll hold them until there’s evidence that that TC wants to do more with Bookmap.
            
            Cheers,
            
            E.
            
            --
            Eliot Kimber
            http://contrext.com
             
            
            
            On 5/22/17, 11:30 AM, "Chris Nitchie" <dita@lists.oasis-open.org on behalf of chris.nitchie@oberontech.com> wrote:
            
                Arguably the biggest problem with the current BookMap design is the inability to use keydef and other topicref specializations at the top level. This makes it difficult to define keys, and impossible to assign <ditavalref> references. To address this issue in DITA 2.0 while keeping the BookMap grammar backwards-compatible with existing documents, I suggest we
                
                - Allow <topicref> and its specializations before <frontmatter>
                - Allow <topicref> and its specializations in the body between <frontmatter> and <backmatter>.
                
                I think this would be all that’s needed to allow BookMap to be more modular and flexible.
                
                Chris
                
                
            
            
            
        
        
    
    
    
    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that 
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php