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