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] Details about how the @processing-role attributefunctions


I think it's important to note that the @processing-role attribute
determines the role of the *reference*, not the topic.

That is, a given reference either does or does not contribute to the
navigation tree of the map, based on the @processing-role attribute. The
same topic may be referenced by two topicrefs, one that is resource-only and
one that is not. The non-resource-only topicref would contribute to the
navigation tree and the topic referenced would be included any
directly-rendered output.

This would be the case, for example, when you have separate keydef elements
for all topics to which keys are bound as well as direct or indirect
references to those topics within the navigation tree or reltable of the
map.

In particular, Tarun's item (3) must be wrong--how a topic referenced from a
relatable is treated is either entirely a function of the @processing-role
attribute of that reference or not affected at all by @processing-role in
that context.

The question of what, if anything, @processing-role means for reltable topic
references is a separate question--I'm not sure that's addressed by the
current spec or by the original proposal--I suspect we didn't think that
aspect through.

A reasonable reading of the spec would, I think, be that topics referenced
by resource-only topicrefs have no linking affect by default (that is, they
do not contribute to navigation). For example, it might be useful to use
relationship tables to associate resource-only topics in some way that is
not intended to be reflected as navigation links in any rendition.

Cheers,

Eliot 

On 5/3/10 2:35 PM, "Kristen James Eberlein" <kris@eberleinconsulting.com>
wrote:

> I've started working through the comments in the DITA markup section and just
> responded to Tarun Garg (Adobe) about a question concerning the
> @processing-role attribute, which I'll copy below. Since the attribute is new
> with DITA 1.2, I'd welcome feedback from other TC members. This topic in
> question is the one titled "DITA map attributes."
> 
> ------------------------
> 
> [Tarun Garg, 30 April 2010] I have a few comments regarding the
> 'processing-role' attribute:
> 
> 1) As per the spec - If this attribute is set as 'resource-only', then the
> topic should not be rendered to output. It is only used for processing. - From
> this I assume that it can be used only as a reference from other topics. But
> since, it itself will not be there in the output, it can only be used for
> conrefs. It cannot be used for xrefs, links, etc. Any other processing purpose
> that it can serve ?
> 
> 2) Does this attribute has any meaning for a topicref inside a reltable? I
> don't think it shall impact the reltable related behavior in any way.
> 
> 3) In case this attribute is set as 'resource-only' for a topicref (outside
> the reltable) and the same topic is referred inside the reltable, then that
> topic shall neither act as a source nor as a target. Based on reltable, adding
> links to/from this topic, does that make sense, as it itself is not rendered
> to output. 
> 
> I think we shall clarify these things as a part of this spec.
> 
> [Eberlein, 3 May 2010]
> 
> (1) Yes, the purpose of the @processing-role attribute is to indicate when a
> DITA topic or DITA map should be used only for processing; the referenced
> topic or map should not be included in the navigation. This is useful for both
> conref and key space resolution; in the latter context keys defined in the map
> specified as "resource-only" may well provide the indirect addresses specified
> for an <xref> or <link>.
> 
> (2) No, it does not have meaning for a <topicref> element within a
> relationship table.
> 
> (3) In this case, I think that the topic referred to within the reltable would
> be built and serve its linking purpose.
> 
> Best,
> 
> Kris
> 
> Kristen James Eberlein
> Principal consultant, Eberlein Consulting
> Secretary, OASIS DITA Technical Committee
> Charter member, OASIS DITA Adoption Committee
> www.eberleinconsulting.com <http://www.eberleinconsulting.com>
> +1 919 682-2290; keberlein (skype)

-- 
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]