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:]
> Sent: Friday, January 04, 2008 6:36 PM
> Cc:
> 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
