Re: [dita] Proposal: Update foreign topic to include processing info forgeneralization/specialization use case

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

Robert D Anderson wrote:
> It seems like - if we support the foreign and unknown element - we have
> these options when using DTDs:
> 
> 1. We state that, if you use the foreign or unknown elements, you have no
> way to share topics with others that do not use your foreign DTD module.
> This would be the only way to make a DITA document that cannot be taken
> back to the topic type that represents a least-common-denominator, because
> you can never share with somebody that does not use this module.

What's to stop you from creating a variant of say the DITA-defined topic 
declarations that allow the foreign content where it will occur in the 
generalized result?

If you are doing the generalization (that is, you are creating a new 
generalized instance) you can certainly also create a variant 
declaration set for that instance that allows the foreign content and 
you can send that DTD along with the generalized instance to whomever 
you are interchanging with.

A DITA processor cannot possibly care where the declarations for a given 
instance to be processed are stored (that's a parser issue, not a 
processor issue) so it can't be a problem for a DITA processor to 
process documents that use different declaration sets.

Note too that a generalization application that *didn't* fully expand 
all defaulted attributes already has to have a pretty sophisticated 
output serializer that knows which attributes have default values and 
what those values are. It can't add that much complexity to also write 
the appropriate DOCTYPE declaration (i.e., the one that points to the 
declaration sets for the generalization with the foreign elements included).

But if a generalizer expands all attributes, then there's not much point 
in having the resulting instance specify a DTD at all since it's not 
needed for correct parsing (there's no markup minimization left) and if 
the input docs are valid the generalized result must be valid.

So I'm not sure that it's really that big of an issue.

Remember that in XML there is only one kind of markup minimization, 
attribute defaults, and if you eliminate that from your instance you 
don't need DTDs except to do validation, and if you trust your content 
to be *semantically* correct (that is, correct enough that you can 
process it to a usable result) then a DTD *has no added value* in that 
case and you therefore don't need it at all.  I would think that the 
generalization use case is exactly this case: you're generally assured 
that the generalized result is valid.

Cheers,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com