Re: [dita] Scoping DITA 1.0 [was: OASIS DITA TC: 07 December 2004 meetingreminder]

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

Michael Priestley wrote:

> During the call I advocated adding a topic to the spec that laid out the 
> costs/benefits for creating new base classes, and potentially covering 
> recommendations for ways to minimize breakage of the architecture when/if 
> breakage becomes inevitable (for example, if new metadata requirements are 
> absolutely required, and otherprops is not acceptable as a workaround).

I think there might be some confusion about at least what I meant when I 
talked about using specialization outside the context of the DITA 
document type.

As far as I'm concerned, if you create your own base types, you have, at 
that moment, thrown aside the DITA document type *in its entirety*. Even 
if you use most of the element types from the DITA document type, by 
introducing new base types or changing the content or the attribute 
rules for existing DITA-defined types, you are creating an entirely new 
document type and should have no expectation of interoperation with the 
DITA-defined document types.

That is, I don't think about it in terms of "adding a new base type". I 
think about it in terms of "defining your own architecture" using the 
DITA specialization mechanism.

That is, I don't think there needs to be a discussion of the "dangers of 
adding a new base type" because it's a nonsensical thing to talk about. 
Either you use DITA as defined as your base types or you create a new 
architecture with its own base types and specializations, its own 
semantics, etc.

There can be no inherent danger in this because it *has nothing to do* 
with the DITA-defined architecture.

There are certainly good practices in defining architecture that should 
be developed and documented, but those would go in white papers or 
technical reports, not specification documents.

Therefore I think it's sufficient to have a paragraph or two to the 
effect that:

"The basic specialization mechanism used by the DITA document types can 
also be used for non-DITA-related document types in order to provide the 
same re-use, specialization, and interoperation benefits that one can 
get from the DITA document types to business-process-specific XML 
applications. Note that even if one uses the DITA-defined types as a 
base, any change to those base types defines a completely new document 
type that has no meaningful or normative relationship to the DITA 
document type and cannot be considered in any way to be a conforming 
DITA application, except to the degree that the syntax and semantics of 
the class= and domain= attributes are preserved."

> But I also feel a bit twitchy about having a section of the specification 
> that effectively introduces a continuum of compliance. I think we do need 
> to talk about these issues, and certainly address them post-1.0, but maybe 
> for 1.0 itself the discussion should take place in an external best 
> practices document, where we are also planning to discuss relationships to 
> other standards, etc.

Per the above, there is no continuum of compliance. Either your 
application conforms to the DITA architecture, which implies 
specialization from only the DITA-defined base types, or it doesn't. If 
it doesn't it cannot be a conforming DITA application.

In practice, of course, I might define a DITA variant that allows 
documents that are easy to transform into pure DITA-compliant documents, 
but that's simply a practical consideration of my system, not an issue 
of compliance (because it's always the case when considering two 
document types that one can transform from one to the other with more or 
less effort and fidelity).

However, the use of the class= and domain= attributes can conform to the 
syntax and semantics for those attributes as defined in the DITA 
specification. Thus there are, at most, two levels of conformance:

- A conforming specialized application. This is an XML application that 
uses the class= and domain= attributes as defined in the DITA 
specification to define its own system of base types and specializations.

- A conforming DITA application. This is an XML application uses or 
specializes from the DITA-defined types as defined without any 
modification of those base types.


But note my terminology problem here: DITA defines two distinct and 
separable things: the specialization mechanism (class= and domain=) and 
the DITA document type. At the moment the term "DITA" subsumes both. One 
reason I prefer a separate specialization specification is that it 
forces us to provide a crisp name for that distict from the DITA 
document type.

But I also recognize the time issues that Paul highlights so I'm willing 
to live with a simple statement in 1.0 such as that given above.

Cheers,

E.

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122

eliot@innodata-isogen.com
www.innodata-isogen.com