Re: [dita] How much flexibility do specializers have to make exceptionsto behaviors that are outlined in the DITA standard?

[Eliot Kimber <ekimber@reallysi.com>]

Ogden, Jeff wrote:

> In our discussions we’ve been talking about “markup/syntax” and 
> “processing behaviors”.  Perhaps we need three categories:
> 
> Markup/syntax;
> 
> Non-appearance related processing behaviors; and
> 
> Appearance related processing behaviors.

I'm not sure what you mean by "markup/syntax"--can you provide examples?

But I definitely agree that there should be a clear separation between 
processing that does not affect appearance (presentation) and processing 
  that is pure presentation.

One way to think of these distinctions is as DITA-to-DITA transforms vs 
DITA-to-rendition transforms. This is more or less reflected in the way 
the Toolkit is implemented: phase one is a DITA-to-DITA transform, phase 
two is a DITA-to-rendition transform.

I think that, with probably very few exceptions, the DITA-to-DITA 
processing (e.g., conref, props= attributes, keyref) must be manditory 
since it reflects core semantics of the DITA standard that are 
independent of whatever rendition might be generated from the data.

[NOTE: Some things, like the presentation result of reltable links, may 
look like DITA-to-DITA processing but they are really pure presentation. 
That is, we cannot necessarily take what the Toolkit does today as a 
definitive guide as to what is manditory processing and what is 
presentation. In the case of relationship tables, the tables simply 
establish abstract relationships: what you do with those relationships 
is entirely a matter of presentation.]

By contrast, the presentation effect of any DITA element has to be 
entirely use-case-specific otherwise there would be no flexibility at 
all (and people would just ignore any such requirements anyway).

For example, I'm in the process of designing a specialization of xref 
that will be used, in the *print rendition*, to position a topic 
relative to some point in another topic. But I'm not changing the core 
semantic of xref (for example, I can't change the addressing rules that 
determine what topic the xref points to).

While the spec can and should describe suggested or default or typical 
presentation effects for given elements, those cannot be normative.

Likewise, while the non-presentation semantics of DITA can be *thought 
of* as DITA-to-DITA transforms, they cannot be normatively defined in 
terms of transformation--they must be normatively defined declaratively 
in terms of the what the effective result is.

That is, any language like "X is transformed to Y" or "X becomes Y" must 
be restated in a way that simply states the post condition (e.g., "the 
effective value is Y"). Non-normative notes can be used to describe 
sample algorithms that produce the correct result, but the algorithms 
themselves cannot be normative, only informative. The XSLT 2 and XSL-FO 
1.1 specifications are excellent examples of combining declarative 
normative specifications with illustrative non-normative procedural 
examples.

Cheers,

Eliot

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com