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

[Eliot Kimber <ekimber@reallysi.com>]

On 12/1/09 8:46 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> I'm a little concerned about this - adding foreign to 1.1 was a big deal,
> and part of the compromise that allowed its addition was support for
> mechanisms that allow exactly the kind of blind generalization up to topic
> that all other sorts of specialization allow.
> 
> If we need to rewrite the section to make it less file-system-specific,
> that's fine. But all sections on generalization have been normative in the
> past, regardless of element. If we take one piece of the generalization
> mechanism and make it non-normative, then we're pretty much giving up on
> blind generalization. That's been a basic feature of the architecture up
> till now.

I think it should it be sufficient to say something like:

"When the result of generalization is a new document with an associated DTD
and that DTD does not provide declarations for any XML content of <foreign>
elements, the generalization processor MAY move non-DITA XML content to
external files referenced by  <object> elements or it may enclose the
non-DITA XML content within a CDATA marked section."

That statement is, I think, sufficient to indicate that the DITA-defined
generalization mechanism provides for the case and also includes both
possible solutions in the validation-required case.

Note that this isn't (or shouldn't be) an issue for XSDs as the content of
<foreign> is xs:any with a processContents of "skip", so it's only an issue
for generalized documents that use DTDs.

The remaining implementation details may or may not need to be spelled out,
but if the intent is to make it clear that the generalization mechanism
provides for the case, then I think my statement does that without imposing
any particular implementation details.

Generalization is a bit odd in that there's really no need for the DITA
standard to say anything normative about the details of how generalization
is done beyond the rules for managing the class, props, and base
attributes--everything else is necessarily implementation details that will
vary based on local requirements.

Cheers,

Eliot

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