RE: [dita] redundancy in `Contains' & `Contained By' sections of archspec topics

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

I've been looking at the eCompress rendition of the 1.1 spec so it
sounds like you've fixed the completely redundant cases for 1.2. I'll
look for the topics that tripped my thinking about this, and send them
to you directly (off the dita alias).

	/Bruce

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Tuesday, June 23, 2009 12:10 PM
> To: Bruce Nevin (bnevin)
> Cc: dita
> Subject: Re: [dita] redundancy in `Contains' & `Contained By' 
> sections of archspec topics
> 
> Hi Bruce -
> 
> Can you point to an example where matching content models 
> show up in two rows? Those values are generated, but I 
> thought I'd fixed all of the cases where content was 
> duplicated. For topicref, for example, there are currently 
> five different rows, all of which have minor differences.
> 
> The values are generated based on the DTD constructs, and are 
> not alphabetical because they show order and cardinality 
> (such as optional topicmeta, followed by any number of A|B|C, 
> followed by other stuff). I did add some logic so that when 
> the tool generating these values recognizes a large group of 
> "or" values - like (this or that or theOther) - it will 
> alphabetize them. However, it is not smart enough to 
> recognize all of the regular expressions involved in the 
> grouping. For example - the topicref element within map shows up as:
> ( (topicmeta)  (optional)  then (anchor or data or data-about 
> or navref or topicref or (anchorref or keydef or mapref or 
> topicgroup or topichead or topicset or topicsetref) or 
> (glossref) )  (any number) )
> 
> The tool is currently alphabetizing the group (anchor or data 
> or data-about or navref or topicref). It's also alphabetizing 
> the next group (anchorref or ... topicsetref). It's not 
> clever enough to merge those groups across the parenthesis 
> boundary - I spent a small amount of time thinking about 
> that, but realized the syntax could always get more complex, 
> and I didn't think I would have time to make it fully reliable.
> 
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit
> 
> 
>                                                               
>              
>              "Bruce Nevin                                     
>              
>              (bnevin)"                                        
>              
>              <bnevin@cisco.com                                
>           To 
>              >                         "dita" 
> <dita@lists.oasis-open.org>  
>                                                               
>           cc 
>              06/23/2009 11:24                                 
>              
>              AM                                               
>      Subject 
>                                        [dita] redundancy in 
> `Contains' &   
>                                        `Contained By' 
> sections of archspec 
>                                        topics                 
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
> 
> 
> 
> 
> Some topics in the architectural spec list two or more 
> doctypes separately although they have the identical content 
> model ('Contains' example:
> topicref); some list more than one doctype in the same table 
> cell to the left of the content model ('Contains' examples: 
> kwd, shortdesk). They should be consistent, and the latter is 
> obviously better.
> 
> Are they automatically generated? (it seems so, given the 
> evidently code-driven order of elements in the lists.) Is 
> this something that is easily fixed?
> 
> Beyond that, it would be "nice" to have lists that are more 
> easily scanned and compared by humans -- alpha order, maybe 
> even one list of elements common to all topic types, followed 
> by per-topic-typ lists of exceptions.
> 
>