Re: [dita] Policy Decision: Loose or Not

Yes, that's a good way of looking at it, Erik.

Now that you mention it, DITA abounds in this kind of "contradiction."

I see no particular reason to eliminate it in the case of ditabase vs
concept et al.

--Dana

Erik Hennum wrote:

  
Hi, Dana, Eliot, and Michael:

  

I'm wondering if the discussion underscores the distinction between a
vocabulary module and a document type shell.

  

The vocabulary module gives the normative definition of a content model
including the base element at each context. For instance, the
definition of <ph> in the topic vocabulary module allows
<keyword> as part of a choice. 

  

The document type shell gives the normative definition for each content
model within that document type after domain substitions and
restrictions have been applied to those contexts.

  

Less formally, the vocabulary module provides the ingredients. The
document type shell assembles the ingredients as a meal.

  

For an example of domain substitions, the topic document type draws on
the programming, software, and UI domains to add the following
substitions in all <keyword> contexts: <option>,
<parmname>, <apiname>, <cmdname>, <msgnum>,
<varname>, and <wintitle>. So, the normative definition of
the <ph> content model for the topic document type provided with
the standard differs from the normative definition of the <ph>
content model for the topic vocabulary module. The two aren't in
conflict because of the nature of domain substitution groups. Other
conformant document type shells are possible that use the topic
vocabulary module but provide a different set of domain substitutions
for the <keyword> element and thus change the definition of the
<ph> content model.

  

For an example of restriction, the concept vocabulary module allows a
nested <topic> in the last context within the content model for
the <concept> element. The concept document type shell restricts
that context to the <concept> specialization of <topic>.
Other conformant document type shells are possible that allow the base
<topic> element in that context or that restrict the same context
to a choice of <concept> or <task> elements.

  

In DITA 1.0, a document type shell can only restrict <topic>
contexts. There is a DITA 1.2 requirement to extend that restriction
capability to any context (which would allow you, for instance, to
restrict the <keyword> context within <ph> to
<apiname> or <cmdname>). 

  

  

Hoping that's useful,

  

  

Erik Hennum



  

  

  Michael
Priestley <>

  

  

  
    
      

        
        
          
            
              
                Michael Priestley
<> 
                
01/24/2007 12:24 PM

              
            
          
        
        
        
        
          
            

              

              
To

              
              

              "W. Eliot Kimber"
<>
            

            

              

              
cc

              
              

              
            

            

              

              
Subject

              
              

              Re: [dita] Policy Decision: Loose or Not
            

          
        
        
          
            

              
              
            

          
        
        
      

    
  
  

  

  

>I think you're misunderstanding the implications of the content
models 

>as shipped: they don't say you *must* do (as in "must allow all
topic 

>types to nest"), they say what you *can* do, from the point of what
is 

>allowed *for specializations*. 

  

The nesting of different topic types is not governed through
specialization: you can change nesting rules without changing
specializations. 

  

Michael Priestley

IBM DITA Architect and Classification Schema PDT Lead



  http://dita.xml.org/blog/25 

  

  
  
    
      

        "W. Eliot Kimber"
<> 
        
01/24/2007 03:04 PM 

        
        
        
          
            

              
              
To

              
              <> 
            

            

              
              
cc

              
              
            

            

              
              
Subject

              
              Re: [dita] Policy
Decision: Loose or Not
            

          
        
        

        
          
            

              
              
            

          
        
        
      

    
  
  

  

  

Michael Priestley wrote:

  

> If we want to ditch normative nesting for one, we should ditch it
for 

> both. Otherwise I don't see how we can say concept must allow
nesting of 

> task in ditabase.dtd, and that's normative, but it can disallow it
in 

> concept.dtd, and that's not.

  

I think you're misunderstanding the implications of the content models 

as shipped: they don't say you *must* do (as in "must allow all topic 

types to nest"), they say what you *can* do, from the point of what is 

allowed *for specializations*.

  

That is, the existence of the value for info-types as declared in the 

ditabase.dtd says "it is, as far as the standard is concerned, OK to 

nest any type within any other type". But it does not say "you must 

allow any type to nest within any other type".

  

Note that using ditabase.dtd as my specialization or configuration
base, 

I can implement exactly the same constraints that the task-specific 

shell DTDs impose.

  

Or said another way, the purpose of the normative part of the 

specification is to define the *minimal set of required constraints* 

needed to make all possible DITA elements sensible and interchangable. 

Anything else we might choose to provide that is more constraining can 

only be a non-normative example or opinion about best practice.

  

Cheers,

  

E.

  

-- 

W. Eliot Kimber

Professional Services

Innodata Isogen

8500 N. Mopac, Suite 402

Austin, TX 78759

(214) 954-5198

  



www.innodata-isogen.com