RE: [dita] processing-role: open items

["Gershon Joseph (gerjosep)" <gerjosep@cisco.com>]

Hi Robert,

Thanks for summarizing the open issues and helping us move this forward.

I'd like to understand the possible use cases of #4 more clearly. I'm
wondering whether the example here should be considered an error
condition processors should generate an error on. If the parent is only
a resource, what's the logic in permitting normal topics inside it? If
the TC feels the stated behavior is good, then I'm fine with that too.
I'm just asking the TC to think through some use cases where this may
apply, and what the "correct" behavior logically would be in such use
cases.

While we're considering use cases, perhaps one or more for #5 would be
helpful for our discussions too.

Does anyone have practical use cases for these scenarios they'd like us
to consider while discussing these?

Gershon

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com] 
Sent: Monday, May 18, 2009 4:27 PM
To: dita
Subject: [dita] processing-role: open items


Last week we agreed that processing-role will default to "resource-only"
on the <keydef> element. From what I can tell in scanning the email
archives, the open items are:

1) Does the attribute cascade to nested topicrefs or through references
to other maps? My thought is yes -- all of the related attributes that
authors would view as processing attributes already do so (print, toc).

2) A related question was, would it cascade from <keydef> as well? I
think this one is clearer - we've established elsewhere that a defaulted
attribute cascades the same as an explicit attribute. That is, the
attributes are all normalized based on the priority defined elsewhere
(explicit attributes, defaulted attributes, controlled values file,
etc).
Once they are normalized, any attribute that cascades does so regardless
of where it came from.

3) Exactly what attributes will processing-role interact with? When
processing-role=normal, there is no change from today. When
processing-role="resource-only", the topic will not be included in any
rendered form of the map; so, we've established that toc is forced to
"no", print is forced to "no". Jeff also mentioned that linking and
search come to mind; I'd agree that linking is forced to "none" for that
topic, and search is forced to "no".

4) The processing-role attribute forces other attributes to take values
such as toc="no". Does toc then become an explicit attribute that
cascades to other values? My thought is no, mostly based on my guess at
what would astonish people the least. I think users would be startled to
have child removed from the toc in the following example:
<topicref href="parent" processing-role="resource-only">
  <topicref href="child" processing-role="normal"/> </topicref>

5) What does it mean to say processing-role="resource-only" print="yes"?
My thought is that @print is ignored on that element, but that both
values cascade, such that print may become useful further down. I find
the use case for this somewhat hard to imagine, but in this contrived
example it would ensure that the child is printed:
<topicref href="grandparent" print="no">
  <topicref href="parent" processing-role="resource-only" print="yes">
    <topicref href="child" processing-role="normal"/>
  </topicref>
</topicref>

Of course, the TC's answer to #4 could invalidate my suggestion for #5.

Thanks -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit


---------------------------------------------------------------------
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_workgroups.php