[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 12055 Map referencing behaviors
This is in reference to the proposal posted here: http://www.oasis-open.org/committees/download.php/24910/IssueNumber12055.html As noted at Tuesday's meeting, there has been some discussion off the list about this item, primarily related to default behaviors. This proposal states that the described behaviors (such as that for cascading metadata) may change in a given specialization. For example, in the general topicref case and in most specializations, metadata specified within the <topicref> applies to the referenced content. This means that a processor could treat specified metadata as if it was specified in the target topicref's. In some cases, the topicref element may be specialized to provide meaning about the referencing context, rather than the target. In that case it may be possible to set metadata that should not cascade to the targets, but should only be used to evaluate the reference itself. As I understand it, the open question is - how should such overrides of the default behavior be defined? If they are not defined within the DTD or Schema, how can a tool anticipate the desired behavior? If they are defined within the DTD or Schema, how can that be done, in a manner that anticipates all of the overrides? If the changes are simply defined in the element documentation, then tools will be unable to automatically understand how to treat the elements, and they will require overrides. Another, I believe less urgent, open question is about the terminology of cascading versus inheritance. It has been suggested that the behaviors described here, as well as in much of the map processing, is more properly described as cascading rather than inheriting. The proposal here uses the term "cascade". When this goes into the specification, it will use the same terminology as the spec, whether that ends up being cascade or inherit. Thanks - Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]