RE: [dita] Issue 12055 Map referencing behaviors

["Ogden, Jeff" <jogden@ptc.com>]

I've lost track.  Is the business about what happens for references
nested within references in the referenced maps included in the
"original proposal".  I think we agreed that this would be
implementation dependent.

    -Jeff

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com]
> Sent: Monday, September 10, 2007 9:29 AM
> To: dita@lists.oasis-open.org
> Subject: Re: [dita] Issue 12055 Map referencing behaviors
> 
> Hi everybody,
> 
> There is still no response to this one, so my plan for tomorrow's
meeting
> is to keep to the original proposal. The specification should describe
> default behaviors for references from one map to another map, but
allow
> that specializations may define alternate behaviors as appropriate.
> Compliant DITA processors should be expected to follow any alternate
> behaviors for OASIS approved elements, because those behaviors must be
> described as part of the specification. However, there is no mechanism
for
> processors to automatically determine the non-default behaviors for
other
> specializations.
> 
> I would be happy to have a way to define non-default behaviors for map
> references. However, I am not sure how to come up with one that is
simple
> enough to use, so it is not a part of this proposal.
> 
> 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 09/05/2007 04:28:03 PM:
> 
> > 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)
> > >
> >