[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 ekimber@innodata-isogen.com www.innodata-isogen.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]