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] Question on keyref processing for <data> element


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



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