How much flexibility do specializers have to make exceptions to behaviors that are outlined in the DITA standard?

["Ogden, Jeff" <jogden@ptc.com>]

We’ve had some e-mail discussions about “How much flexibility specializers have to make exceptions to behaviors that are outlined in the DITA standard”. But those discussions have been fairly quiet for 10 days or so.  We had some good discussion of this during the last DITA TC meeting.  During that discussion we agreed to move the discussion back to the DITA TC e-mail list.  

 

So this note is my attempt to get the e-mail discussion restarted.

 

I don’t think we want to talk about this issue during tomorrow’s DITA TC call, but if we can get some good discussion going on the e-mail list we may be ready to talk about it during next week’s call.

 

I think Gershon’s draft meeting minutes provide a pretty good summary of the discussion, so far. From the draft 9 October 2007 meeting minutes:

 

          4) How much flexibility do specializers have to make exceptions to

            behaviors that are outlined in the DITA standard?

 

                JO: We had good discussions. MP has a more liberal approach,

                whereas I feel we should not permit as much flexibility.

 

                MP: I'm drawing the line between syntax and behavior. Syntax

                must be preserved. Everything beyond there is pretty contextual.

 

                JE: There are edge cases where we've had to deviate from the

                standard in order to achieve the specialization we needed.

                Though these are minor deviations that could be easily

                transformed back into standard DITA.

 

                Discussion...

 

                MP: If someone wants to override the stated default behavior

                (for some good reason), I don't think we should call that going

                against the DITA spec.

 

                Discussion...

 

                Don requested we move this discussion to the email list.

 

                Yet further discussion...

 

                Don asked us to take items 3 and 4 off into 2 discussions next

                week. In the meantime, continue discussions on-list.

 

Much of the discussion so far has been between Michael and me.  I’d like to see if we can get some others to express their views on this issue.  If most people don’t care or if most people agree with Michael that specializers can do pretty much anything they want, we may not need a lot more discussion.  If this position makes some people uneasy, then we need to find that out and we will need to continue the discussion to figure out how and where to draw some lines.

 

I believe that there is agreement that specializers have a lot of control and can change many things related to output processing behaviors of their specializations. I think there is also agreement that we need to review the DITA specifications to make sure they are clear about what MUST, SHOULD, or MAY be done with respect to both the basic DITA document types that are officially part of the standard (topic, map, concept, glossary, reference, task, and bookmap) and for user defined specializations that aren’t a formal part of the standard. I am a little less sure, but I think there is agreement that we want to add some sort of conformance statement to the DITA specifications.

 

The question that is up for discussion is, are specializers free to do anything they want or are there some things that the DITA Standard makes out of bounds even for user defined specializations that aren’t part of the official DITA standard?

 

From my point of view, I’d like to see some limits on what specializers can do in terms of referencing behaviors (what legal DITA URI’s can look like and what they mean), and when there are interactions such as property cascading behavior between one document and another (from a map to a topic or from a map to a map to a topic).  I want to increase the likelihood that DITA users can share their documents, including specialized documents, with others or move the documents into new processing environments and still get good results.  I want to reduce the amount of reimplementation users have to do when they share their documents or move into new processing environments.

 

Paul Grosso described this in terms of the distinction that is made in XSLT between transformations and styling. Styling would be very open and specializers could do pretty much whatever they want.  Transformations (explicit or implied) would be more tightly defined by the DITA Standard and specializers would have less flexibility (but still some flexibility).  Paul, feel free to restate this if what I wrote here isn’t quite right.

 

I’ll shut up now. Please let us know what you think.

 

   -Jeff