[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Foreign Generalization: Should be moved to a non-normativeappendix
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]