RE: [dita] Issue 12055 Map referencing behaviors

["Grosso, Paul" <pgrosso@ptc.com>]

Robert,

If I understand correctly, you are suggesting that different
specializations can do different things based only on some
writeup in the standard.

Jeff and I have said that is the one choice we find unacceptable.
Either there needs to be some machine-readable way to determine
behavior (e.g., encode it in the DTD/XSDs), or all behavior must
be consistent.  Having to hardwire potentially conflictly behavior 
into an implementation for each specialization is not a good option.

Jeff and I will try to discuss this some more before tomorrow's
meeting, but I wanted to respond as soon as possible.

paul

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Monday, 2007 September 10 8:29
> 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/IssueN
> umber12055.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)
> > >
> >
>