Forwarding to the list, since Eliot's email alias doesn't work on my system.
-----Original Message-----
From: Dana Spradley
Sent: Monday, July 06, 2009 11:34 AM
To: Eliot Kimber; Ogden, Jeff; dita
Subject: RE: [dita] Re: DocBook vs DITA customization (was RE: [dita] some comemnts on the Draft DITA 1.2 architecture spec.)
I don't think we're fundamentally in disagreement, Eliot - it's more a matter of tone and nuance.
I do disagree, though, that DITA has nothing really distinguishing to offer people who aren't interested in blind interchange. DITA has a great deal to offer someone shopping around for a standard to base their customization on - not only the topic orientation you mention, but code reduction through class attributes tracing element relationships, a well developed element and attribute vocabulary, content-based tables, conrefs, maps, etc. and authoring and publishing tools that support these features in an agnostic fashion, without requiring full DITA conformance.
I think we limit DITA's market acceptance by language in the specification that "tightens the screws," as you say, on people considering DITA who see these features' value, but who see little or no value in their particular case for blind interchange.
As you say, "Of course, within an enterprise or community, you are free to do whatever you want, you just
can't call it DITA conforming if it's not DITA conforming."
That's all I'm really asking for right now, I think - recognition in the standard that people may choose to apply it in this fashion - the way that most other OASIS standards do, through a section that glances at true customization at the end.
Long term, though, perhaps we should revisit the issue of the cost that strict conformance in support of blind interchange and round-trip generalization places on the architecture and people who adopt it, and consider loosening some requirements and turning them into recommendations or making them entirely optional, or defining a "loose" version of DITA that does this.
I wonder where members of the Adoption Committee stand on this issue? It seems reasonable to allow DITA to be different things to different people to a certain extent.
--Dana
-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com]
Sent: Monday, July 06, 2009 10:39 AM
To: Dana Spradley; Ogden, Jeff; dita
Subject: [dita] Re: DocBook vs DITA customization (was RE: [dita] some comemnts on the Draft DITA 1.2 architecture spec.)
Unless I'm misunderstanding what you mean by "DocBook-style customization",
I could not disagree more.
That DITA disallows uncontrolled extension is the reason DITA works at all.
The DITA standard *must* disallow it in order for DITA to be what DITA is,
that is, a mechanism that enables blind interchange of content in a way that
no other XML application can or does.
Note that everything in DITA about modular information and topic-oriented
writing is really not distinguishing, or for a large potential community of
users, particularly interesting.
What is distinguishing and compelling about DITA is the specialization
feature and the attendant constraints around conref and map composition that
enable blind interchange and interoperation of *any* conforming DITA content
with any other conforming DITA content. That is the one aspect of DITA that
*no other standard* offers and, without which, they all fail, to one degree
or another, to deliver on the promise of generalized markup to enable
interchange of content and processing. Before DITA, the idea that XML (and
SGML before it) enabled interchange was a Big Lie because it provably didn't
work. With DITA it works. But it works because DITA tightens the screws.
That is, content that uses DITA as a base but does not conform to the DITA
constraints *cannot be* DITA content as sanctioned by the DITA standard
because such content *is not reliably interchanged*. Of course, within an
enterprise or community, you are free to do whatever you want, you just
can't call it DITA conforming if it's not DITA conforming.
The point of the current text, certainly as I understood it's motivation,
was to make it clear that things that are SOP in other XML applications are
*absolutely not allowed* in DITA because they break interchange and
operability but that the TC recognizes there are practical reasons for doing
those things within your own purview and we just want to be clear that,
having done those things, what you have is not conforming DITA content.
Cheers,
E.
On 7/6/09 12:26 PM, "Dana Spradley"