RE: [dita] Policy Decision: Loose or Not

From
JoAnn Hackos <>
Date
2007-01-24T12:16:30+00:00
ID
Thread
RE: [dita] Policy Decision: Loose or Not
I certainly agree that a loose structure has a practical 
value for some activities, but it is being seriously corrupted by people who 
have convinced others that DITA "does not work." They use ditabase to turn DITA 
into a sequential book structure. They eliminate DITA map because it is 
inconvenient and means less money for them to maintain the mess they've created. 

 

As Yas suggests, it might be quickly deprecated to allow 
those who want intertwined bookish structures to move to 
Docbook.

 

JoAnn

 

JoAnn T. Hackos, PhD
President
Comtech Services, 
Inc.
710 Kipling 
Street, Suite 400
Denver CO 80215
303-232-7586


 

 

From: Yas Etessam 
[mailto:] 
Sent: Tuesday, January 23, 2007 6:01 
PM
To: 
Subject: RE: [dita] Policy 
Decision: Loose or Not

Implementors 
can already constrain users to 
single typed topics by changing the doctype to use the appropriate concept/task/concept/reference DTD.  

 

In terms of conversion, there could be cases where legacy 
conversion to DITA would result in a single topic with mixed 
information type sub-topics. 

In terms of specialization, ditabase is 
intentionally lax to serve as an appropriate base for specialization.  

 

I agree with JoAnn that authoring with ditabase might not 
follow the best practice but I don't see the justification for eliminating it 
for DITA 1.1.    

 

Lets consider leaving ditabase loose and encourage 
implementors to use the single-typed DTDs for the appropriate information 
type.  Providing a ditabase DTD for composite documents might be an option 
that some users, conversion vendors and specializers might want to 
keep.  

 

Finally, this feels like a large change given the 
timeline for DITA 1.1's release.  If the rest of the TC members feel 
strongly that it should be eliminated,  I'd hope that we'd start with 
deprecation rather than elimination.

 

Yas Etessam   

 

From: JoAnn Hackos 
[mailto:] 
Sent: Tuesday, January 23, 
2007 4:10 PM
To: Dana Spradley; 

Subject: RE: [dita] Policy Decision: Loose 
or Not

  

  
This is my position exactly. Let's eliminate ditabase. 
  I'm attending a meeting this week battling with a "consultant" who has used 
  ditabase to recreate docbook inside a dita topic.The entire book is in one 
  topic. It's infuriating that people want to corrupt the entire 
  concept.

  
 

  
JoAnn

  

  
JoAnn T. Hackos, 
  PhD
President
Comtech Services, 
  Inc.
710 Kipling 
  Street, Suite 400
Denver CO 80215
303-232-7586


  
 

  
 

  

  
  From: Dana Spradley 
  [mailto:] 
Sent: Tuesday, January 23, 2007 
  5:04 PM
To: 
Subject: Re: [dita] 
  Policy Decision: Loose or Not

  

Then the most logical choice would be to 
  eliminate ditabase from the standard - and let implementors do their own 
  ditabases as a practical measure, if they want to give authors a way of 
  writing non-conformant topic collections prior to splitting them up into 
  conformant topics.

--Dana

W. Eliot Kimber wrote:

  Dana 
    Spradley wrote: 

    This would be a rather extreme change of policy, 
      wouldn't it? 

As I understand it, ditabase is expliticly 
      *non*-normative, and as the spec currently says any nesting or other 
      arrangement of topics in it "has no particular output implications; it 
      simply allows you to create multiple topics of different types at the same 
      level in a single document." 

Unless I've completely 
    misunderstood the implications of how things are delivered, all the 
    declarations are normative. That is, the DITA standard consists of the 
    architecture specification, the language reference, and the accompanying DTD 
    and XSD declarations, all of which are normative. 

That is, the very 
    fact that we need to have language in the language reference about when 
    different containment rules apply indicates that we have two different but 
    normative rules. 

If it wasn't normative then we wouldn't have the 
    language in the spec. 

Cheers, 

E.