OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: Policy Decision: Loose or Not


Per the discussion between Michael P. and myself with regard to the 
differences between the topic nesting constraints defined by the 
ditabase declaration set and the type-specific declaration sets, I think 
there is a policy decision that the TC needs to make and then reflect 
consistently in the spec and declarations.

If I understand Michael's justification for having two different sets of 
rules for how topics can nest, it is that there is a pragmatic need to 
allow unconstrained nesting but a desire to show that one can specialize 
the declarations to disallow it and thus the declarations as provided 
have two different sets of rules. He also asserts that most authors want 
the more constrained set of rules.

My position is that the declarations as defined in the standard should 
be both consistent and relaxed, such that the standard does not *impose* 
any constraints that are not necessary to impose. In this case it is 
clear that, for example, restricting reference to only containing 
reference is not necessary *because ditabase doesn't do it*.

That is, as a matter of *standards policy*, the standard should only 
define as normative only those constraints that are appropriate, leaving 
all other constraints to specializers.

At the same time, I recognize that Michael is probably correct that most 
DITA users would want the more constrained version of the content models.

One solution would be to say that the declarations as configured by the 
ditabase declaration set are the *normative* declarations and the 
topic-type-specific declarations (concept.dtd, task.dtd, reference.dtd, 
glossary.dtd) are non-normative examples of how to configure the 
declarations to tighten the looseness of the normative configuration.

That would remove the need to refer to the type-specific configurations 
at all in the DITA reference, since only the ditabase configuration 
would be normative.

Note that this would not change in any way the status or nature of the 
type-specfic declaration modules (the group and module declarations).

But I think that it's very important that in terms of the normative 
dictates of the standard, that we be both consistent and loose.

Unless there is serious opposition to this idea, I will plan to make a 
motion to this effect at our next meeting.

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com



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