OASIS Darwin Information Typing Architecture (DITA) TC

  • 1.  RE: [dita] Policy Decision: Loose or Not

    Posted 01-24-2007 12:17
    
    
    
    
    
    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
    joann.hackos@comtech-serv.com

     


    From: Yas Etessam [mailto:yas.etessam@xmetal.com]
    Sent: Tuesday, January 23, 2007 6:01 PM
    To: dita@lists.oasis-open.org
    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:joann.hackos@comtech-serv.com]
    Sent: Tuesday, January 23, 2007 4:10 PM
    To: Dana Spradley; dita@lists.oasis-open.org
    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
    joann.hackos@comtech-serv.com

     


    From: Dana Spradley [mailto:dana.spradley@oracle.com]
    Sent: Tuesday, January 23, 2007 5:04 PM
    To: dita@lists.oasis-open.org
    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.


  • 2.  RE: [dita] Policy Decision: Loose or Not

    Posted 01-24-2007 13:06
    
    
    
    
    
    It's way too late to do something like deprecate ditabase in 1.1.
     
    paul


    From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
    Sent: Wednesday, 2007 January 24 06:16
    To: Yas Etessam; dita@lists.oasis-open.org
    Subject: 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
    joann.hackos@comtech-serv.com

     


    From: Yas Etessam [mailto:yas.etessam@xmetal.com]
    Sent: Tuesday, January 23, 2007 6:01 PM
    To: dita@lists.oasis-open.org
    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:joann.hackos@comtech-serv.com]
    Sent: Tuesday, January 23, 2007 4:10 PM
    To: Dana Spradley; dita@lists.oasis-open.org
    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
    joann.hackos@comtech-serv.com

     


    From: Dana Spradley [mailto:dana.spradley@oracle.com]
    Sent: Tuesday, January 23, 2007 5:04 PM
    To: dita@lists.oasis-open.org
    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.