[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] TractorX Example
I don't think it would be appropriate for the proposal to specify an approach to processing; that needs to be up to implementers. I'm happy to add language to the proposal and/or the spec pointing out that different instances of the same topic with different effective key spaces *should* result in unique content artifacts in the output, but not going so far as to say a DITA processor *must* perform some complicated procedure to ensure the smallest possible footprint and least possible redundancy in the output. I also want to point out that this situation isn't unique to key scopes. It also appears whenever two instances of a topic appear in a map with different <topicmeta> on their respective topicrefs. It will also be an issue if we include new DITAVAL-related features such that different DITAVALs might be in effect for different sections of an output publication (though which proposal(s) might imply such behavior escape me at the moment). And although the DITA OT does presume a 1-to-1 mapping of input topic to output HTML file (allowing for chunking and copy-to and so on), there are other processors that presume that each iteration of a topic is unique, and these changes won't have any impact on such processors, at least not as far as this issue is concerned. Chris -----Original Message----- From: Dawn Stevens [mailto:dawn.stevens@comtech-serv.com] Sent: Wednesday, April 10, 2013 3:32 PM To: Eliot Kimber; Chris Nitchie; JoAnn Hackos; dita Subject: RE: [dita] TractorX Example Eliot, In this example, your point is quite relevant as they are outputting to HTML. If I understand you correctly, in order to have new result instances for each set of keys the author would have to manually set a copy-to whenever the key definitions were different. To avoid this manual effort, this proposal would need to suggest either 1) a blind treatment of all topics with a keyref to be treated as though @copy-to were specified or 2) a complicated analysis to determine if the keys result in differences so that only the different results are treated with an automated @copy-to. Does one or the other of these options need to be explicitly included in this proposal? If so which one is being suggested? I would certainly favor the later for ease in authoring and more streamlined output, even recognizing the resulting processor overhead. Best, Dawn -----Original Message----- From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Eliot Kimber Sent: Wednesday, April 10, 2013 9:11 AM To: Chris Nitchie; JoAnn Hackos; dita Subject: Re: [dita] TractorX Example On 4/10/13 10:01 AM, "Chris Nitchie" <chris.nitchie@oberontech.com> wrote: Any of the topics could have conkeyrefs to modelConrefs/modelName, > modelConrefs/modelDescription, etc. Because of the presence of > @keyscope on the model-level map, those key references will resolve to > the Olocal¹ binding for the modelConrefs key, without interfering with > the binding for that key in the other model maps. Also, the > electricalSystem.dita file could have conkeyrefs to > electricalConrefs/whatever that would resolve differently for each > instance, due to the presence of @keyscope on the topicgroups. And > because those Oelec-*¹ scopes are children of the Omodel¹ scopes, they > can also reference modelConrefs/*, and get the appropriate bindings for the current model. This points up a potential complicating/surprising aspect of having scoped keys: processors that produce modular outputs, like HTML, are obligated in practice to produce a unique output instance for each *use* of a given topic, which the OT, for example, does not currently do today. Today you use @copy-to to manually force creation of new result modules when you need them. But when each use of a topic could result in different resources for the same conkeyref or xref, then the simplest thing for a processor to do is just blindly treat each use as though @copy-to had been specified. Of course, a processor could analyze the topics to determine whether or not it contained references to any scoped keys and then only generate new result instances when there were some, but that would be hard and would add a lot of processing overhead, at least without more sophisticated preprocessing of topics or support from some sort of component management system to maintain that knowledge for quick access. I don't have a problem with this behavior--I think it's generally required anyway, but I know that Michael and Robert have argued convincingly for not requiring it. For monolithic outputs like PDF it doesn't matter because each use of a topic results in a unique rendering of that topic by the nature of the output. Cheers, Eliot -- Eliot Kimber Senior Solutions Architect, RSI Content Solutions "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.rsicms.com www.rsuitecms.com Book: DITA For Practitioners, from XML Press, http://xmlpress.net/publications/dita/practitioners-1/ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]