OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]