OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  Re: [dita] index terms

    Posted 10-03-2005 16:58
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    dita message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: [dita] index terms


    Chris Wong wrote:
    
    > My point is that we cannot assume DITA adopters will not be
    > print-centric, nor can we tell print-centric users to bugger off.
    
    I think this is the disconnect: DITA is explicitly *not* print centric. 
    It was originally designed to do things that *were not books* and what 
    facilities it has for doing book-type deliverables are, while not an 
    afterthought, definitely not the primary focus of its design.
    
    What I'm saying is that some users of DITA may have made a suboptimal 
    technology choice if sophisticated book-centric publishing is a primary 
    requirement. That's just a fact and their inappropriate choice doesn't 
    necessarily obligate us, as a standards development body, to reorder our 
    priorities.
    
    As a standards development body, just like any other development group, 
    we have to carefully manage the scope of what we're doing. DITA has 
    clearly defined, from the beginning, that sophisticated book publishing 
    is outside its scope. To the degree that holding that line means telling 
    some users to "bugger off" then we have to do that. DITA can't be all 
    things to all users. DITA will always be under presure to add features 
    that are outside of its scope. Sometimes we have to make hard decisions 
    about what to take on and what not to take on.
    
    But at the same time, DITA can be extended unilaterally and I think that 
    sophisticated indexing is exactly the place to take advantage of that. 
    If there is a community of DITA users who really need more indexing than 
    DITA can easily provide with a minimum of design effort, that community 
    can drive its own development activity, whether its within a single 
    enterprise or an ad-hoc collaborative effort: i.e., start a project on 
    Source Forge.
    
    In the case of Idiom as a business, a business that is explicitly 
    selling DITA-based solutions (see www.idiominc.com), I see an 
    opportunity to offer additional value by providing a well-architected 
    indexing solution on top of core DITA. But just because a company like 
    Idiom or Innodata Isogen, both companies that try to sell DITA-based 
    products and services, have customers that have requirements that DITA 
    doesn't currently meet doesn't necessarily mean that those features have 
    to go into the core DITA design. Precisely because of DITA's inherent 
    extensibility we, as a marketplace, can offer value-added solutions, 
    some of which might eventually become part of core DITA, some of which 
    might not.
    
    Sophisticated indexing is just one example of a requirement that core 
    DITA will not ever satisfy. But DITA provides a built-in mechanism for 
    those requirements to be satisfied by third parties in an architected way.
    
    Cheers,
    
    Eliot
    -- 
    W. Eliot Kimber
    Professional Services
    Innodata Isogen
    9390 Research Blvd, #410
    Austin, TX 78759
    (512) 372-8841
    
    ekimber@innodata-isogen.com
    www.innodata-isogen.com
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]