[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Conditional processing with the @rev attribute
|
Thanks
Michael for the prompt clarification. The about-ditaval topic for both DITA 1.1
and DITA 1.2 is clear about no filtering for @rev, however I think that both the
archspec and the language reference should say that there is no filtering for
@rev, in addition to the language reference linking prominently to the
about-ditaval topic. The language reference for @rev is not clear to me: For
DITA 1.1 it says: “Indicates revision level of an element. It is useful
for flagging outputs based on revision. If no value is specified, but the
attribute is specified on an ancestor within a map or within the related-links
section, the value will inherit from the closest ancestor.” (
http://docs.oasis-open.org/dita/v1.1/CD02/langspec/common/select-atts.html ) For
DITA 1.2 it says: “Indicates a revision level of an element that
identifies when the element was added or modified. It may be used to
flag outputs when it matches a run-time parameter. It is not sufficient to be
used for full version control, such as single-sourcing multiple product
variants based on version level, as it only represents one aspect of the
revision level. If no value is specified, but the attribute is specified on an
ancestor within a map or within the related-links section, the value will
cascade from the closest ancestor.” ( http://docs.oasis-open.org/dita/v1.2/cd03/spec/common/select-atts.html#select-atts
) Neither
of these currently says to me “no filtering”. Also I don’t
understand this sentence: “It is not sufficient to be used for full
version control, such as single-sourcing multiple product variants based on
version level, as it only represents one aspect of the revision level.”
Where are the other aspects of the revision level stored? Is revision level the
same as version level? What does the term “sufficient to be used for full
version control” mean in terms of how processors are expected to
treat an attribute? Cheers, Su-Laine Su-Laine Yeo JustSystems Canada, Inc. XMetaL Community Forums: http://forums.xmetal.com/ From: Michael Priestley
[mailto:mpriestl@ca.ibm.com]
Hi everyone, As far as I know, the @rev
attribute has always been included in the list of conditional processing
attributes (http://docs.oasis-open.org/dita/v1.1/CD02/archspec/condproc.html). I don’t know of anything in
the DITA 1.1 spec that says that it
should be processed
differently from the
other conditional processing attributes. However, AFAIK the Open
Toolkit ignores DITAVAL
statements to exclude content based on @rev, and a recent statement from Michael was that “rev cannot be used for
filtering”: http://tech.groups.yahoo.com/group/dita-users/message/17821
. It’s not clear to me whether
Michael’s statement is a statement of how the OT currently behaves or if
it’s a statement of how the OT should
behave. The draft DITA 1.2 spec
deepens my confusion. It says, “DITA
defines five attributes that are specifically intended to enable filtering or
flagging of individual elements. Those
attributes are @audience, @platform, @product, @otherprops, and @props.”
But then a few paragraphs later under a
section titled “Conditional
processing attributes” it lists six
attributes including @rev. So is @rev a conditional
processing attribute or not? What
is our expectation from processors?
a) Processors should filter based on @rev if instructed to do so by the DITAVAL
file b) Processors may choose to filter based on @rev if instructed to do so by the DITAVAL file c) Processors must never
filter based on @rev
regardless of what the DITAVAL file says In my opinion, the wording
of the DITA 1.1 spec indicates option A or B, so we can’t change the
expected behaviour to C without
breaking backwards-compatibility. Su-Laine Su-Laine Yeo JustSystems Canada, Inc. XMetaL Community Forums:
http://forums.xmetal.com/
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]