RE: [dita] How much flexibility do specializers have to make exceptions tobehaviors that are outlined in the DITA standard?

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

Just to reiterate my earlier position
- I think all processing behaviors that are used in a publishing pipeline
are ultimately about appearance. We just have a number of separate publishing
processes that have shared components. We are now visiting the question
of whether the parts of those processes that are shared or common (such
as conref, map-based linking...) should be regulated by the spec to the
extent that they cannot be extended or customized by someone implementing
a new publishing process.

Our original publishing transform for
dita2html did conref and link processing in the same pass as the transform
to HTML. Now they are in three separate passes, at least in the DITA open
toolkit. This makes each process more robust and shareable, but does it
mean they should be less customizable?

If a customization breaks the semantics
of the thing being customized (such as a conref customization abusing the
syntax of the conref attribute), then that's wrong; but where a customization
respects the semantics and syntax of the source, I think it's an offense
to the spirit of XML (separating markup from behavior to allow multiple
behaviors) to prevent customizations. And I think that's true regardless
of the category we put the processing into.

Michael Priestley
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Ogden, Jeff" <jogden@ptc.com>

01/07/2008 09:13 AM

To	"Eliot Kimber" <ekimber@reallysi.com>
cc	<dita@lists.oasis-open.org>
Subject	RE: [dita] How much flexibility do specializers have to make exceptions to behaviors that are outlined in the DITA standard?

Eliot asked:
> I'm not sure what you
mean by "markup/syntax"--can you provide examples?
 
In this discussion we’ve been talking
about “markup/syntax” vs. “processing behaviors”.
 
I think we could have been using the
terms “syntax” and “semantics” instead.
 
I think “markup/syntax” is pretty
much anything that is controlled by a DTD as well as the rules for how
one creates new valid DITA DTDs. “processing behaviors” are everything
else.  But “everything else” is too broad to be useful and that
is the reason for the suggestion to split this into at least two sub-categories:
 “appearance processing behaviors” and “non-appearance processing
behaviors”.
 
   -Jeff
 
> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Friday, January 04, 2008
6:36 PM
> Cc: dita@lists.oasis-open.org
> Subject: Re: [dita] How much flexibility
do specializers have to make
> exceptions to behaviors that are
outlined in the DITA standard?
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail
list, you must leave the OASIS TC that
> generates this mail.  You
may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php