[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] redundancy in `Contains' & `Contained By' sections of archspectopics
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]