RE: [dita] Question: local content in <abbreviated-form> element with keyref

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

As I read the description in 3.2.4.2.1, the content of the
<abbreviated-form> element "should" never be rendered. In its place, the
content of one of the elements in the referenced <glossentry> topic
"should" be rendered, the choice depending on the context. Consequently,
the content of the <abbreviated-form> element "should" be no more than a
mnemonic to the author.

That way, the author's topic don't have empty <term> elements in them
(or specializations thereof, like this).

On the other hand, why pay translators to translate content that is
never rendered? That would be an advantage of leaving them empty as
indicated in the lang ref. Translate once in the glossary, and instruct
translators how to understand the <abbreviated-form> element in context
if their tools are not capable of rendering them properly.

	/Bruce

> -----Original Message-----
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com] 
> Sent: Tuesday, April 26, 2011 7:40 PM
> To: dita
> Subject: RE: [dita] Question: local content in 
> <abbreviated-form> element with keyref
> 
> By the way, as a writer I would also be squeamish about 
> putting empty <term> elements (with keyref attributes 
> resolving to terms in topicmeta) in topics. The topic would 
> only be comprehensible in the context of a map and in a 
> keyref-aware display tool. I imagine that the tools used by 
> translators, in particular, will probably not be able to make 
> topics display in a meaningfully complete way if they are 
> full empty <term> elements. 
> 
> I would rather use conkeyref than keyref for swapping out 
> variable content, because with conkeyref I can put fallback 
> text in the keyref-bearing element. For abbreviations, 
> however, conkeyref won't work.
> 
> Su-Laine
> 
> -----Original Message-----
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Tuesday, April 26, 2011 3:23 PM
> To: dita
> Subject: [dita] Question: local content in <abbreviated-form> 
> element with keyref
> 
> Sorry folks, yet another issue which needs to be scrutinized 
> before finally-final-finalizing item #3 here:
> http://wiki.oasis-open.org/dita/Review-FAQ-
> 
> Consider this scenario:
> 
> <p>An <abbreviated-form keyref="abs">anti-lock braking 
> system</abbreviated-form> helps a driver to stop.</p>
> 
> The spec does not seem to cover this scenario:
> http://docs.oasis-open.org/dita/v1.2/os/spec/langref/abbreviat
> ed-form.ht
> ml#abbreviated-form
> 
> For keyref processing in general, we have decided that the 
> content of the keyref-bearing element should always be 
> displayed if it exists.
> However, for <abbreviated-form> processing I'm starting to 
> think that local content should lose if the key can be 
> resolved to a <glossAcronym>. If we have local content always 
> win, the only way to have the feature work will be to leave 
> the <abbreviated-form> element empty. But to be safe, 
> practitioners should put something reasonable in 
> <abbreviated-form> so that there is fallback text if the 
> keyref can't be resolved or if the processor is not 
> sophisticated enough to do the special processing required to 
> render abbreviations. 
> 
> 
> Cheers,
> Su-Laine
> 
> Su-Laine Yeo
> Solutions Consultant
> JustSystems Canada, Inc.
> Office: 1 (778) 327-6356
> syeo@justsystems.com
> 
> XMetaL Community Forums: http://forums.xmetal.com For 
> partners only: http://www.justpartnercenter.com
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.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_workgr
> oups.php 
> 
>