Re: @processing-role related issues

[Eliot Kimber <ekimber@reallysi.com>]

On 8/25/10 2:52 AM, "Tarun Garg" <tarung@adobe.com> wrote:

> Hi Eliot,
> 
> I don't think there is any practical usage of having @processing-role as
> "normal" when it is set as "resource-only" for an ancestor.
> Hence, I suggested to define such a usage as invalid in the specification
> itself, so as to minimize the accidents :).

We're saying that it should behave like @toc, so if you have a descendant
that specifies @processing-role="normal" it's treated normally, regardless
of ancestry.

Whether that's a sensible thing to do or not is irrelevant, it's doable and
that behavior is most consistent with existing DITA behavior for @toc. Since
both cases are essentially about determining contribution to navigation, it
makes sense for them to be consistent.

In general the specification tries not to mandate "sensibility" since it's
hard to predict when something is or is not sensible. Rather we try to
produce the least surprise for a given combination of components.

Cheers,

E.


> 
> Regards,
> Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com
> 
> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Tuesday, August 24, 2010 11:49 PM
> To: Tarun Garg; dita-comment@lists.oasis-open.org
> Subject: Re: @processing-role related issues
> 
> Tarun,
> 
> The intent of the specification is that an explicit value of "normal" for
> @processing-role should always cause the inclusion of the referenced topic
> in the navigation tree. That is, @processing-role should be consistent with
> the semantic of @toc, where a value of "yes" for @toc includes that topicref
> in the ToC even if its parent says @toc="no".
> 
> There is a statement in section 2.1.3.2 Navigation behaviors (the first list
> item in the list of cases where a topicref does not contribute to
> navigation) that seems to imply that ancestor values of "resource-only" for
> @processing-role override explicitly-specified values of "normal". This
> statement is incorrect and will be corrected to something like:
> 
> '* The effective value of the @processing-role attribute for the topicref
> element is "resource-only"'
> 
> Thus, in your use case, topic T2 would be included in the navigation because
> it explicitly specifies @processing-role="normal".
> 
> Do you have any real-world cases where this might occur? We couldn't think
> of any practical reason to have this case in practice, although of course an
> author might create this combination of topicrefs accidently.
> 
> Thank you for your comment and your careful reading of the specification.
> 
> Cheers,
> 
> Eliot Kimber
> 
> 
> Original comment:
>> Consider a case,  where @processing-role is set as Oresource-onlyı for a
>> topicref (say T1). And this topicref has a child topicref (say T2) for which
>> the @processing-role is set as Onormalı. This may cause issues in processing.
>> T1 shall not be a part of the output as per the description of this
>> attribute.
>> But T2 shall be there in the output. But itıs not clear what would the
>> hierarchy reflect in the output in navigation/toc, as the parent of T2.
>> 
>> 
>> 
>> I think this shall be treated as follows:
>> 
>> ·         T2 shall be eliminated from the output irrespective of the value of
>> @processing-role for T2. This is because itıs parent T1 is set to be excluded
>> from the output using this attribute.
>> 
>> ·         So, in general an element shall be excluded from the output, if the
>> @processing-role is set as Oresource-onlyı for any of its ancestors. This
>> shall happen irrespective of the value of @processing-role at the current
>> element.
>> 
>> 
>> 
>> 
>> 
>> Regards,
>> 
>> Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.reallysi.com
> www.rsuitecms.com
> 

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com