My own thought here is that we have three options:
- Define standard behavior that applies to all cases, no
exceptions.
- Say that the behavior is implementation dependent,
possibly giving an example of a desired behavior that may be implemented.
- Provide a standard behavior and a way to designate
exceptions to that standard behavior.
For this particular case I don’t think #3 would be too
hard and so that would seem to be a good way to go.
I am uncomfortable with the option that is being proposed which
I take as defining standard behavior, but allowing exceptions. The reason
I am uncomfortable with this is that it requires that someone who wants to
define a new specialization that requires exceptions provide both the
specialized elements and behavior. We have a standard way to provide the
specialized elements. We do not have a standard way to provide the specialized
behavior. Without a standard way to provide the specialized behavior, someone
will need to reimplement the specialized behavior for different output
processing implementations. That will be extra work and seems likely to result
in different results as documents are moved from site to site and
implementation to implementation. We should avoid that if we can.
I could live with option #1 (no exceptions). That puts
the burden on the author to use the “right” map elements when the
behavior they want isn’t the standard behavior.
I could live with option #2 (no standard). That is
what we do for most output processing today.
And as I said, I think option #3 is the best approach.
I think all we need is either:
a)
a new attribute similar to domain on the root element
of a map that accepts a space separated list of topicref specializations whose
behavior should not be overridden when they are referenced using a different element
from a higher level map, or
b)
a new attribute similar to class on topicref and
topicref specializations that indicates that this element’s behavior
should not be overridden when referenced from a higher level map.
In either case, like domain or class, the new attribute would
usually appear with its default value in a DTD or schema and not in the
instance.
And, if we want to, rather than using a simple list or a
single attribute value, we might define a keyword or grouping syntax for the
values so that we could use the same attributes for other similar purposes in
the future should the need arise. Some possible approaches:
Simple
list on the root element: norefoverride=”element1 element2 …
elementn”
Single
valued attribute on the topicref element or specialization: refoverride=”no”
Grouping syntax on the root element:
processing_exceptions=”norefoverride(element1
element2 … elementn) somenewoption(somenewvalues)”
Keyword
list on any element: processing_exceptions=”norefoverride somenewoption
someothernewoption”
-Jeff
From: Michael
Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Monday, September 10, 2007
12:06 PM
To: Grosso, Paul
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Issue 12055
Map referencing behaviors
I think the wording needs some clarification - I don't
think what you're reacting to is actually Robert's intent.
Robert,
I'm going to try to paraphrase here:
If
someone specializes a map to create a new map-referencing element, they can
define specialized processing for that element if they want. Applications that
are not customized or extended to provide special handling for the specialized
element should instead treat the specialized element according to its ancestry
(ie, according to whatever behavior is provided in the spec for that element).
I
don't think Robert is saying more than the above, and that's true of all
specializations. He's just pointing out that the behavior defined in the spec can
be overridden by someone providing specialized elements and behavior.
Why
is it worth calling out at all then? I think because there are some behaviors
that we consider architectural (eg conref, the class attribute...) that need to
be consistent across specializations because they are designed to provide
interoperability across specializations; there are other behaviors that are
implementation-specific, in which the behaviors we provide are defaults that
can be overridden, rather than normative for the class of all possible DITA
document types. I think map-referencing behaviors fall in the latter class, and
that's what Robert is trying to say.
Robert,
correct me if I'm wrong. Paul, does that re-interpretation address your
concerns?
Michael
Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Grosso, Paul"
<pgrosso@ptc.com>
09/10/2007 11:27 AM
|
To
|
<dita@lists.oasis-open.org>
|
cc
|
|
Subject
|
RE: [dita] Issue 12055 Map referencing
behaviors
|
|
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)
> > >
> >
>