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: Re: [dita] Policy Decision: Loose or Not


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."

It's just a crazy quilt for the convenience of authors in a hurry, for topics that need to be split up and organized via a map later.

It would be odd to suddenly prefer its content model as the normative standard.

W. Eliot Kimber wrote:
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



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