OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

RE: [dita] DITA namespace?

  • 1.  RE: [dita] DITA namespace?

    Posted 02-07-2006 18:47
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    dita message

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


    Subject: RE: [dita] DITA namespace?


    I'm not against namespaces, but they do make me very
    nervous, especially when they get introduced into
    existing vocabularies--because they, by definition,
    create a new vocabulary.
     
    DITA 1.0 does have the DITAArchVersion attribute in the
     
    And I thought folks like Eliot agreed that was enough to
    allow him to recognize DITA content and reference schemas
    as needed.
     
    So in what way do you mean "DITA doesn't have a namespace right now"?
     
    And in what way do "tools that depend on namespace to associate a document
    with its schema" still "probably do need one"?
     
    I'm not sure how to answer #1 and #2 below, but I would point
    out that #2 (processing) includes more than just the official
    toolkit.  There are users out there writing their own code
    (XSLT and otherwise), and not all that code will work without
    modifications (or complete rewrites) if we add namespaces.
     
    I'd like to have a better idea just what the advantages
    are of adding namespaces so that I can make a better
    cost/benefit analysis.  Right now, I see lots of costs,
    but I don't have a good understanding of the potential
    benefits.
     
    paul


    From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
    Sent: Tuesday, 2006 February 07 11:11
    To: dita@lists.oasis-open.org
    Subject: [dita] DITA namespace?


    There are a lot of tools that depend on namespace to associate a document with its schema or processing. DITA doesn't have a namespace right now, but we probably do need one. The issues are:

    1.-would new namespaced content be backwards compatible with tools and editors?
    2. could processing handle a mix of namespaced and non-namespaced DITA content?
    3.  what do we tell specializers to do?

    In an ideal world, it would be nice to have a separate namespace for every DITA specialization: but the issue we had with that in our previous discussion was the usability of a compound document that would include so many different namespaces, and the inability to default more than one of them.

    If we can answer 1 and 2 in the positive, maybe the position for 1.1 could be:

    - provide a single "dita" namespace for all base DITA markup (eg topic, task, concept, reference, various domains)
    - if necessary, provide an un-namespaced version as well, for backwards compatibility with any existing tools/implementations
    - tell specializers to either create their specializations in the existing "dita" namespace, or in no namespace, or in their own namespace, at their discretion (as long as the result can still be processed and edited as DITA topics based on class attributes etc.)

    And defer to the future the question of whether we can overcome the technical and usability challenges involved in synchronizing namespaces and design modules in DITA, ie having the topic type or domain name as the automatic namespace for any specialization.

    Michael Priestley
    IBM DITA Architect
    Classification Schema PDT Lead
    mpriestl@ca.ibm.com


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