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 @xtrc). 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. Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting
www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 6/22/2016 2:40 AM,
jang@jang.nl wrote: 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 yet. 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. Jang Op 22 juni 2016 00:27:12 +02:00, schreef 'DITA TC' <
dita@lists.oasis-open.org> : 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. Jim From:
dita@lists.oasis-open.org [ mailto:
dita@lists.oasis-open.org ] On Behalf Of Eliot Kimber Sent: June-14-16 11:35 AM To: DITA TC Subject: Re: [dita] DITA 2.0: suggest removing @xtrf, @xtrc I agree with Robert and Chris: remove them. Cheers, E. ---- Eliot Kimber, Owner Contrext, LLC
http://contrext.com From: dita <
dita@lists.oasis-open.org > on behalf of Chris Nitchie <
chris.nitchie@oberontech.com > Date: Tuesday, June 14, 2016 at 1:25 PM To: Robert Anderson <
robander@us.ibm.com >, dita <
dita@lists.oasis-open.org > Subject: Re: [dita] DITA 2.0: suggest removing @xtrf, @xtrc I agree. 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). Chris From: <
dita@lists.oasis-open.org > on behalf of Robert D Anderson <
robander@us.ibm.com > Date: Tuesday, June 14, 2016 at 2:19 PM To: DITA TC <
dita@lists.oasis-open.org > Subject: [dita] DITA 2.0: suggest removing @xtrf, @xtrc For DITA 2.0, I'd like to suggest removing @xtrf and @xtrc, also known as the debug attribute group :
http://docs.oasis-open.org/dita/dita/v1.3/os/part1-base/langRef/attributes/debugAttributes.html#global-atts 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 processing , although I'm not aware of any others defined in that way. Regards, Robert D. Anderson DITA-OT lead and Co-editor DITA 1.3 specification , Digital Services Group E-mail:
robander@us.ibm.com Digital Services Group 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA