dita — archive

[Eliot Kimber]

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