OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] DITA 2.0: suggest removing @xtrf, @xtrc

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.


Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
+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.


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.





From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Eliot Kimber
Sent: June-14-16 11:35 AM
Subject: Re: [dita] DITA 2.0: suggest removing @xtrf, @xtrc


I agree with Robert and Chris: remove them.







Eliot Kimber, Owner

Contrext, LLC


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).




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":

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.


Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification,
Digital Services Group

11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]