dita — archive

[Michael Priestley <mpriestl@ca.ibm.com>]

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


>