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] Standard DITA processing instructions?

I think the DITA TC could include discussion of “DITA standard PIs” in the spec.


I think having something standard for change tracking would be a good thing, but I wonder if that might not be better done in a way that would work for DITA and non-DITA document types.  And if you buy into that, the question is what group would be a good one to work on it?  I guess it could be a recommendation from the DITA TC that had wider application than just DITA, but I can imagine that there may be some other group that might be appropriate and willing to do that work too.


I think you have to look at using PIs vs. more traditional element/attribute markup on a case by case basis.


An advantage of PIs is that implementations that don’t understand or support a particular PI should ignore them.  That isn’t as true for element markup.


In the case of change tracking, I think there could be some real advantages to using PIs.




From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Friday, October 02, 2009 2:12 PM
To: Park Seth-R01164
Cc: dita
Subject: Re: [dita] Standard DITA processing instructions?


My usual thought is that if we want to standardize it, why make it PIs, which by their very nature cannot be controlled by a schema?

For example, for change tracking there's already some attributes that might be used - but if we wanted something new, we could create a domain specialized from <data> and make it broadly available.

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect


"Park Seth-R01164" <seth.park@freescale.com>


"dita" <dita@lists.oasis-open.org>


10/02/2009 02:04 PM


[dita] Standard DITA processing instructions?


I hope this is not taboo to suggest, but...
Is it in the TC purview to provide a way for DITA application developers to undergo some level of coordination for processing-instructions for common user events?
For instance, if there were a common nomenclature for "change tracking" PI notation, an author, editor, reviewer, and publisher could use the most appropriate tool for his/her specific function and the change tracking feature would work across those different purpose-specific tools.
Something like this would allow DITA files to be exchanged where not only the content is guaranteed to be interoperable, but also commonly used application "features".
bracing for the blow,

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