Jang, our plan for DITA 2.0 is to remove certain elements and
attributes, especially if they duplicate functionality (such as
<topicsetref>) or were ill-advised to begin with (@xtrf and
If you (or someone else) needs these attributes, you can create
an attribute specialization for them. These attributes are
picture-perfect candidates for specializations of @base, because
are expected to go everywhere.
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
+1 919 682-2290; kriseberlein (skype)
I am using these attributes for traceability, which entails
more than just debugging a processor. When comments or changes
are made to published content, these attributes allow me to
trace the comment back to the source. We are quickly moving into
a world where users can talk back in many different ways, and it
would not be very sensible to kick this mechanism out of the
standard just because not many people are using its potential
I agree that authors should not need to deal with these
attributes and they can be easily hidden in any DITA editing
environment. This is also true for @class and a bunch of other
attributes. The fact that authors should not be bothered with
attributes is therefore not really a convincing reason to scrap
the attribute from the specs.
Agreed to remove
them – their use is likely not interoperable (kind
of attributes use in many ways).
Although there may
be people using them but the DITA standard is not
currently in the business of processing.
I have always had
the idea however, that the OT should define
“preprocessing” validity using DTDs. If this could
be handled as a valid modification to the DITA DTDs
that would be great.
This would mean
that a DITA repository could store and validate OT
preprocessed DITA using DITA specializations such as
the debug attributes.
agree with Robert and Chris: remove them.
Unlike copy-to, I have used these in my
implementations, both for debugging and for
traceability from output HTML elements to
source XML elements. But they’re not to be
used by authors, and so probably shouldn’t be
there (but as Robert says, they can still be
added by processors for whatever purposes).
DITA 2.0, I'd like to suggest removing @xtrf
and @xtrc, also known as the "debug
Sort of like with last week's discussion of
copy-to, these attributes were really
defined based on a specific processing model
(the step-by-step toolkit style processing),
with the idea that debug information can be
carried through that sort of process while
keeping the DITA itself valid according to
the original schema.
I don't think that's appropriate for the
core DITA specification itself. Applications
like DITA-OT can continue to operate in
exactly that way, using those exact
attributes, without the two of them being
part of the specification. I think that
would be true of any attribute defined as "intended
to store xxxx during intermediate
I'm not aware of any others defined in that