RE: [dita] Issue 12055 Map referencing behaviors

After some initial discussion on the DITA TC list a smaller group of interested folks (Michael, Robert, Erik, PaulG, and me) have been continuing the discussion about Issue 12055, “Map referencing behaviors”, among ourselves. It is time to bring the issue back to the entire TC, have a discussion of the issue during next week's DITA TC call, and if everything goes well during that discussion, schedule a vote on this issue for the following week.

Robert's proposal is available at:

http://www.oasis-open.org/committees/download.php/24910/IssueNumber12055.html

There has been general agreement on most of this proposal all along. The recent discussion has been about how much flexibility specializers have to depart from the standard behavior described in the proposal and, if there is flexibility, how this can be communicated (in a write-up for the specialization, as XSLT or other implementation specific code, as something encoded in the DTD or schema, …). The feeling now is that the question of how much flexibility a specializer has and how that information is communicated isn’t something that is limited to map referencing behaviors, but is in fact a much larger question that should be taken up by the TC in a separate discussion.

So we would like to suggest that issue 12055 go forward for consideration by the TC now with the understanding that the write-up that gets added to the DITA Architecture Specification will “tone down” the discussion of exceptions for specializations so that it is similar to other existing sections of the Architecture Specification that deal with this same issue.

And separately we want to bring the issue of exceptions for specializations or really what parts of the DITA Standard are mandates and what parts are descriptions of the expected default behavior up for discussion by the DITA TC as a whole.

-Jeff Ogden

PTC/Arbortext DITA Development Lead

> -----Original Message-----

> From: Robert D Anderson [mailto:robander@us.ibm.com]

> Sent: Wednesday, September 05, 2007 5:28 PM

> To: dita@lists.oasis-open.org

> Subject: Re: [dita] Issue 12055 Map referencing behaviors

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

> >

dita message