OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]