Re: [dita] Foreign Generalization: Should be moved to a non-normativeappendix

[Eliot Kimber <ekimber@reallysi.com>]

I want to see if we have arrived at a decision on this issue.

Here's where I think things stand technically:

1. We have determined that moving foreign content to side files with
<object> elements is the only reliably-reversible solution for transforming
to DITA documents where DTD validation of the foreign content may not or is
not provided for. [The transform is not required for XSD validation nor is
it required when the result documents are not validated.]

2. Because (1) is not obvious, it is necessary to describe the use case and
the solution in the spec somewhere.

3. In order to support interoperation of generalization processors, the
details of how foreign is converted to <object> and side files needs to be
at least a SHOULD, if not a MUST (it is currently a MUST as written). In
particular, the data="DITA-foreign" convention is required to enable
recognition of <object> elements that were generated from <foreign> content
and can/should be turned back into <foreign> content when respecializing or
otherwise transforming to a new DITA target document type.

That leaves, I think, the following decisions to be made:

1. Are the transformation details MUST or SHOULD requirements?

2. Should the discussion be grouped with more general discussion of
generalization or should it be a separate topic? Keep in mind that the need
to create side files is independent of generalization, but the reversibility
of the transform is a generalization requirement (or rather, it's needed to
support generalization, although it would also support other DITA-to-DITA
transform use cases).

3. Where should this discussion be? It is currently in the Specialization
section.

My proposal is as follows:

1. Move the discussion of Generalization from Specialization to Processing.

2. Keep the current "Generalization of foreign content" pretty much as it
is, but relax any MUST statements to SHOULD. Relax the discussion of file
names to make it clearer that the primary requirement is the creation of
uniquely-named files and that specific filenaming rules are just
suggestions, not SHOULD or MUST requirements.

Because generalization is a process performed on DITA content, I think it
belongs in the Processing section. I am content to leave the discussion of
handling <foreign> with the larger generalization discussion since it is
required by generalization, even if it's not specific to it.

I can do this rework if there is agreement on the approach.

At a minimum we need to relax the current foreign generalization topic to
remove any MUST statements and make it clear that the process described is
the only way it *could* work, not an arbitrary process imposed in the name
of interoperation.

Cheers,

Eliot

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