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: Bug in definition of @collection-type in DTD


Found this while working on attribute table updates, and I think it needs some TC input.

Specifically, we define @collection-type in two different ways. It's used on many elements in <map>, all based off of one original definition that is reproduced throughout our map modules. The map usage defines values unordered/ordered/family/choice/-dita-use-conref-target. The attribute in our specification is based on this set of values. This is consistent in every map element that uses the attribute.

We also define @collection-type on <linklist> and <linkpool>. In the spec, we reuse the same definition. In the XSD, it has the same values. In the DTD we ship, it has an additional value of "tree". I don't know where this comes from. Best guess, it was a pre-OASIS idea that was never defined, and was removed from all of the map modules but not the topic module.

As with similar problems I've found recently, the specification is officially canonical. I did not know the value existed, and found it by accident (extra caution working on the attribute tables). But, given that it has been in our DTDs since 1.0, I'm not sure we can remove it (similar to the typo @longdescre attribute we discussed a week or two ago). If we are unable to remove it, then I suggest adding a line to the linklist/linkpool elements indicating that the value is undefined and will be removed in the future.

Thoughts?

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)



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