[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Foreign Generalization: Should be moved to a non-normative appendix
The 1.1 spec and the 2nd review draft of the 1.2 spec include the topic "Foreign generalization", which defines a specific set of rules for how to handle the content of <foreign> elements during a generalization process. Paul Gross logged the comment: The discussion (preceding the examples) in "Foreign generalization" is too prescriptive for a standard. It gets right down to describing specific processing and even the file name to use. This needs to be rewritten to describe intent, not a detailed implementation of that intent. I agree with Paul: this topic is defining implementation details that are not appropriate as normative requirements. The process outlined in the current topic is a potentially useful implementation choice for handing foreign elements in a way that ensures they won't interfere with the validation of generalized documents, but since not all generalization processes need result in literal document instances nor would such instances necessarily be validated, it's clearly not appropriate as a normative requirement. I think the appropriate thing to do with this topic is to move it to a non-normative appendix and present it as one way of managing the processing of generalized documents with foreign content. Note that the only actual potential problem is validation of generalized result documents when the DTD or schema used for the generalized instance is either synthesized dynamically or invariant and not defined by somebody familiar with the documents being generalized. That is, there is no problem in generalizing specializations of <foreign> themselves, nor is there a problem generalizing any XML content they have, since generalization of the content isn't relevant (because it's not DITA, by definition). The only practical problem is validation of the generalized result when two things are true: 1. You want to validate the generalized documents 2. You haven't pre-defined their shells to include the DTD or XSD components needed to validate the XML content of <foreign> elements. This can really only be the case when you are doing generalization to <topic> using the TC-provided shell (or, more likely, a shell that includes no domains). If you are controlling precisely what the generalization targets are then you very likely know enough about the documents involved to have pre-created a generalization shell that can provide for the validation of XML content of <foreign> elements. It also occurs to me that if we had another vocabulary module type, "foreign vocabularies", there would be no problem because the @domains attribute would provide enough information to synthesize a shell that included the necessary foreign element validation components. I will propose just this for 1.3. Cheers, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]