OASIS Darwin Information Typing Architecture (DITA) TC

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.

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)"                                                     
             

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
                                                
                                                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)"                                        
>              
>              

My reply doesn't appear in the thread on the web, though a cc was sent
to the dita alias. Gershon, you are correct, it appears that Robert had
already caught these, so this is a no-op. You can close it.

	/Bruce



> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Bruce Nevin (bnevin) 
> Sent: Tuesday, June 23, 2009 2:11 PM
> To: Robert D Anderson
> Cc: dita
> Subject: RE: [dita] redundancy in `Contains' & `Contained By' 
> sections of archspec topics
> 
> 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)"                                        
> >              
> >