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: RE: [dita] redundancy in `Contains' & `Contained By' sections of archspec topics


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-----
> 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)"                                        
> >              
> >              <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.
> > 
> > 
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
> 


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