RE: [dita] TractorX Example

["Chris Nitchie" <chris.nitchie@oberontech.com>]

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