I think you may be confusing two different domains of processing. The text about not processing <data> is specifically in the context of final renditions--<data> elements should be *reflected* in renditions by default. In the case of effective link text even if a <data> element is carried through into the effective markup for a linking element, the subsequent *rendition* processing of that <data> element would be to ignore its content. At least that's how I read and understand the treatment of <data>. But this seems like an edge case since I think it would be fairly rare to put <data> elements within keywords terms in topic metadata--at least no obvious use case for that comes to mind. Cheers, E. On 2/21/11 4:11 PM, "Su-Laine Yeo" <
su-laine.yeo@justsystems.com> wrote: > Hi everyone, > > (I'm drafting a longer response to the "Question on key resolution for complex > <topicmeta> content" thread. To keep that one focused I'm splitting this > question out into a different thread.) > > The language reference for the <data> element > (
http://docs.oasis-open.org/dita/v1.2/os/spec/langref/data.html#data > <
http://docs.oasis-open.org/dita/v1.2/os/spec/langref/data.html#data > ) says: > > "Processors should ignore the content of the <data> element by default, so the > <data> element should only be used for properties and not to embed text for > formatting as part of the flow of the topic body. It might be tempting to > specialize the <data> element for text that is part of the body flow, so as to > escape the constraints of the base content models. This abuse of the DITA > architecture will cause problems. For example, if a particular kind of > paragraph is specialized from <data> rather than from <p>, then when the > content is exchanged with others that do not recognize the specialized > element, their processors will skip the content." > > The architectural specification > (
http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/processing_key_referenc > es.html > <
http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/processing_key_referenc > es.html> ) says: > > "For elements that in addition to @keyref or @conkeyref do specify an > > @href attribute (such as author, data, data-about, image, link, lq, > > navref, publisher, source, topicref, xref, and their specializations), > > matching content includes all elements from within the key definition > > element that are in valid context within the key reference." > > The language reference says that processors should ignore <data> by default, > but the architectural specfication says that it should be processed. Which is > correct? If we follow the letter of the architectural specification, then if > you have: > > <keydef keys = "fooimage"> > > <topicmeta><data><image href="foo.gif"/><data></topicmeta> > > </keydef> > > And > > <topic> > > S > > <data keyref = "fooimage"></data> > > S > > </topic> > > Then it would seem that processors would be required to resolve the image at > the location of the <data> element in the topic, but this does not sound like > it's in the spirit of the description of the language reference. > > Cheers, > > Su-Laine > > Su-Laine Yeo > Solutions Consultant > > JustSystems Canada, Inc. > Office: 1 (778) 327-6356 >
syeo@justsystems.com < mailto:
syeo@justsystems.com > > > XMetaL Community Forums:
http://forums.xmetal.com > > For partners only:
http://www.justpartnercenter.com > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368
www.reallysi.com www.rsuitecms.com