RE: [dita] TractorX Example

[Dawn Stevens <dawn.stevens@comtech-serv.com>]

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