Re: [dita] My comments about DITA applicability torequirements and a separate standard for specialization

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

ehixson@bmc.com wrote:

> Even worse, we would be locked out of any possibility of content
> interchange with our business partners.

That's not strictly true--you can always achieve interchange via 
transformation at relatively low cost, but I appreciate that you may 
have decided that it was better to be able to do direct interchange. I'm 
just saying that you've overstated the case here a bit.

   The
> new, specialized element itself is what denotes the semantics, not
> the name of the base class.  

This is where I strongly disagree as a matter of practice: the base type 
contributes to the overall classification of the element type and 
therefore to its semantics.

The above approach is something I would never do, but I do recognize 
that not everyone takes the same hard line I do. Nevertheless I will 
continue to protest that I think this is very bad practice that will 
lead to (avoidable) pain in future. But I think I've made that point.

   Also, when DITA evolves to contain new
> base classes in the TOPIC doctype, it's a trivial task to redefine
> the CLASS attributes in our custom doctypes to point to a new, more
> semantically equivalent base class.

This is true and if there was some critical need for me to use DITA 
as-is today I would fall back to this plan. But I would only go this 
route if I was confident that there will eventually be appropriate types 
in DITA.

> You can safely "break" DITA and redefine a base class as long as you
> make your redefinition more restrictive than the original.  For
> example, it's safe to redefine SECTION.CNT in topic.mod as follows:

I don't see this as "breaking" anything--it's a fundamental 
specialization technique and can never be wrong *as long as* you don't 
eliminate something that is required by the base class. That is, if the 
base class allows A or B and you only want to allow A that's fine. But 
if the base class requires A and allows B, and you don't want A at all, 
then you've broken DITA because naive receivers of your documents will 
have a reasonable expectation of finding an A where one is required by 
the base class.

Restricting the occurence of optional content cannot break interchange. 
Failing to provide required content is likely to break interchange.

[Aside: As a matter of base class design, things should only be required 
when the information would simply not work or would be nonsensical 
without those things. For example, a topic without a title is probably 
nonsensical since a fundamental property of a topic is a title that 
helps to distinguish it from all other topics.

But the current topic model requires body, even though a topic without a 
body but with required subtopics is arguably perfectly meaningful (even 
though it might not be good writing practice).

This is an example where current DITA is too restrictive, probably 
reflecting a business rule decision that IBM made (subtopics shall 
always be introduced) but that is inappropriate, in a general standard, 
to impose on everyone.]

> What this buys you is a large degree of restrictive flexibility for
> your authors, yet your document instances are all still valid against
> base DITA and will process just fine.  

There's no need to have separate DTDs *as long as* your modified DTD can 
only produce instances that also conform to the (less restrictive) DITA 
DTDs.

It is for this very reason that I never consider the possibility of 
directly using the DITA declaration sets for my documents--I assume that 
I will always being doing restriction or specialization (to new types, 
not just to restrictions of existing types). Therefore I assume that 
I'll be modifying the declarations, at which point the overhead of the 
highly parameterized declaration sets just gets in my way. But maybe 
that's just me.

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