OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

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

01/07/2008 09:13 AM

"Eliot Kimber" <ekimber@reallysi.com>
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”.
> -----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
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]