Re: [dita] Issue 12055 Map referencing behaviors

[Robert D Anderson <robander@us.ibm.com>]

In an attempt to draw out more responses on this one ...

The issue under discussion is how to define differences in behaviors. To
make it easier, I will give a specific example.

We have a chapter element defined in bookmap. When this points to a map, it
casts the referenced material in the role of a chapter, or a sequence of
chapters if there are multiple top-level elements. Attributes and metadata
will cascade to the referenced 'chapters'.

Within IBM we have another specialization, <topicsetref>. This is used to
point to commonly reused branches on a map. The behavior here differs - the
referenced material clearly is not cast into the role of a topicsetref.
Additionally, the topicsetref element defaults @type to 'topicset', which
indicates the type of the referenced target but should not be passed to the
targets. So, the map referencing behavior differs between chapter and
topicsetref.

Because map is the most general DITA collection structure, it should allow
appropriate processing based on the type of the collection and the type of
the collected content objects.  That is, standard DITA map processing
behaviors are defaults appropriate to default DITA topics but don't
preclude other processing behaviors.

Options mentioned so far for defining this are:
1) We specializers must expect to override programs to get anything
different from the default.
2) We define overridable behaviors; programs may try to make it easier to
supply overrides to implement alternate behaviors
3) Any behavior that differs from the default must be encoded in the DTD or
Schema (using a new, to-be-defined notation)
4) OASIS approved elements that differ from the default must define the
difference in the specification. Default support for these differences
should be expected in processors, but simple support for differences in
user-created specializations is not guaranteed

My own preference is for #1, because a) I think that differences from the
default should be expected, and b) I think defining those behaviors in the
DTD or Schema will be prohibitively complex. I would also be happy with #2,
although I do not think we can come up with a full list of overrides, just
like we cannot come up with a full list of specializations. If somebody can
suggest a DTD or Schema notation that is expandable and simple enough to
use for any case that might come up, I would readily shift my allegiance to
#3.

Thanks -


Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)

Robert D Anderson/Rochester/IBM@IBMUS wrote on 08/30/2007 04:56:00 PM:

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