Robert,
As Paul said in his note,
what you proposed looks pretty good to us. Here are a few comments,
questions, or requests for clarification.
Just to confirm: @processing-role
doesn't have a default value specified in the DTD or schema for most elements,
but when there is a DTD or schema default, that is the value that applies
unless a value is explicitly given on the element. And when there is no explicit
value, no default value in the DTD or schema, and no value that cascades from
ancestors, then the processor supplied default for @processing-role is
"normal".
OK, so far?
You proposed:
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.
This seems fine, but we
just want to clarify that @processing-role cascades within a map, but does not
cascade from map to map. Is that your understanding?
Dave and I share the
concern that Gershon expressed in his note. I wonder if one way to handle
this is to go forward with what you proposed, but add something along these
lines:
Processors
MAY, but are not required to, produce a warning when the effective value for
@processing-role conflicts with or will override explicit settings for @toc,
@print, @search, or @linking on a particular element.
-Jeff
> -----Original Message-----
> From: Grosso, Paul [mailto:]
> Sent: Tuesday, May 19, 2009 9:51 AM
> To: Robert D Anderson; dita
> Subject: RE: [dita] processing-role: open items
>
> Robert,
>
> Thanks for this summary.
>
> I believe we'll have agreement on most of what you say here,
> but there are some subtleties that still need to be discussed,
> and unfortunately I have to miss today's TC telcon, so I'd
> ask that the TC make no final decision on this topic just yet.
>
> We (Jeff, Dave, and I) plan to send email in response to further
> the discussion as soon as we can.
>
> paul
>
> > -----Original Message-----
> > From: Robert D Anderson [mailto:]
> > Sent: Monday, 2009 May 18 8:27
> > 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_workgr
> oups.php
> >
> >
>
> ---------------------------------------------------------------------
> 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
