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

["Eliot Kimber" <ekimber@reallysi.com>]

On 10/15/07 4:39 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> The question that is up for discussion is, are specializers free to do
> anything they want or are there some things that the DITA Standard makes
> out of bounds even for user defined specializations that aren't part of
> the official DITA standard?

> From my point of view, I'd like to see some limits on what specializers
> can do in terms of referencing behaviors (what legal DITA URI's can look
> like and what they mean), and when there are interactions such as
> property cascading behavior between one document and another (from a map
> to a topic or from a map to a map to a topic).  I want to increase the
> likelihood that DITA users can share their documents, including
> specialized documents, with others or move the documents into new
> processing environments and still get good results.  I want to reduce
> the amount of reimplementation users have to do when they share their
> documents or move into new processing environments.

The DITA specification defines a number of core processing semantics that
constitute the core processing infrastructure that makes DITA both work
functionally (that is, when implemented, those features produce the result
that you presumably want because you're using DITA) and allows documents and
document processing to be reasonably interchangeable.

I think that this infrastructure includes the following:

- All addressing of DITA-governed content by DITA-governed content. That is,
you cannot, within a specialization, change the rules for resolving hrefs
(or any other DITA-defined addressing mechanism)) to DITA-based content.

- Conref. You cannot change the constraints or effective result that conref
produces.

Where things start to get a little cloudier, and where I think this
discussion started, is in the area of the implications for topic references
and in particular how do topic references affect the effective properties of
the topics they reference?

The issue here is that while this area can be viewed as concrete in the way
that addressing and conref are, it can also be seen as a matter of
presentation style. For example, for some specializations of metadata used
within topicref I want their values to propagate and replace values on
referenced topics and for other values I do not. A blanket DITA-defined rule
of "metadata always propagates" or "metadata never propagates" would be
wrong some of the time so we can't define it. That leads to Paul's original
question of how can specializations express their intent in a case like this
that allows a tool like Arbortext Editor to do the expected thing
automatically? Clearly in this specific case there's a need for some sort of
schema-level way to indicate the processing intent.

Simple enough to design for this case, but how many cases are there?
Probably lots. That suggests you need a more general mechanism for this sort
of thing. That will be, necessarily, complex. Easier to just punt and say
"DITA has no opinion". But that doesn't help Paul. Seems like, for the
moment, there's no easy answer to this question.

At a minimum DITA has to define clear default behaviors for those areas
where processors can legitimately do different things.

I guess I would need to see some specific cases where a specialization wants
to deviate from either the defined or suggested behavior to evaluate whether
or not the deviation is processing or style, there's a way to usefully
parameterize the behavior choices or whether the requirement can be
satisfied in a different way. Or where, as above, DITA either says nothing
or isn't clear and there are multiple useful ways that a processor could
behave.

It's also worth saying that while DITA should "just work" that's always in
terms of the default behavior, whatever it is, as defined by the DITA spec.
Specializations that want something other than the default are on their own
and there should be no expectation on anyone's part that
specialization-specific stuff will magically happen without some
implementation effort.

In that respect, DITA-based applications are no different from any other
purpose-built XML application in that you may have to do a bit of local
customization of your generic tools to get what you want. However, with DITA
it should always be less (or no greater than) it would have otherwise been
because DITA gives you so much out of the box.

For example, for demonstration purposes I've defined a specialization of
reference for capturing animal field guide entries, including
specializations of <data> for capturing the Linnaean classification of the
animals described. No DITA-aware processor is going to give me any special
support for authoring these classifications but I'd probably want to build a
little classification editor for these values since they need to be
validated and could be gathered from external data sources and whatnot. I
would not fault any DITA-supporting editor for not providing that but I
would expect a way to add it without too much difficulty.

Cheers,

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

Sent using the Microsoft Entourage 2004 for Mac Test Drive.