dita — archive

Issue 12055 Map referencing behaviors

From: Michael Priestley <[email protected]>
To: [email protected]
Date: Mon, 10 Sep 2007 19:18:00 -0000

Re:

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

Actually we do - see the architectural spec section "Specialization in processing".

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

It's within the scope of normal DITA specialization to create a new specialized element that has specialized processing. Some of the critics of specialization have claimed that's the norm, which it's not, but it's not the exception either. As one example, I believe the DITA Open Toolkit provides specialized behaviors for about a third of the specialized elements in the DITA spec. I believe most DITA users that are specializing DITA are also providing specialized processing for at least some of their new elements.

Michael Priestley
Lead IBM DITA Architect
[email protected]
http://dita.xml.org/blog/25

"Ogden, Jeff" <[email protected]>

09/10/2007 03:05 PM

To	Michael Priestley/Toronto/IBM@IBMCA, "Grosso, Paul" <[email protected]>
cc	<[email protected]>
Subject	RE: [dita] Issue 12055 Map referencing behaviors

My own thought here is that we have three options:

1. Define standard behavior that applies to all cases, no exceptions.

2. Say that the behavior is implementation dependent, possibly giving an example of a desired behavior that may be implemented.

3. 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:[email protected]]
Sent: Monday, September 10, 2007 12:06 PM
To: Grosso, Paul
Cc: [email protected]
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
[email protected]
http://dita.xml.org/blog/25

"Grosso, Paul" <[email protected]>

09/10/2007 11:27 AM

To	<[email protected]>
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

>