MUST means that an implementer MUST
provide this default behavior.
I think the alternative is to render
specialization powerless to introduce new behaviors that conflict with
the base. Which, given that half the motivation for specialization is to
do something beyond what the base does, would render useless about half
the specializations already out there.
Also note that the existing spec, since
1.0, has a whole section on how to manage processing overrides. If we want
to disallow processing overrides, that's a funny thing to have in the spec.
One of the main points of specialization
is that all behavior is default, and may be overridden by a specializer.
This is nothing new, so I think/hope we're just talking past each other.
Michael Priestley
Lead IBM DITA Architect
http://dita.xml.org/blog/25
"Grosso, Paul"
<>
10/02/2007 02:23 PM
To
<>
cc
Subject
RE: [dita] MUST, SHOULD, and MAY, some
key words from RFC 2119
If I'm not misunderstanding
what you're saying, Michael, that is the most unusual definition of "standard"
I have ever seen in my quarter century of working on standards.
Then what does it mean to
be MUST in the core DITA standard?
More to the point, what
is the core DITA standard standardizing?
paul
From: Michael Priestley [mailto:]
Sent: Tuesday, 2007 October 02 13:15
To: Ogden, Jeff
Cc:
Subject: Re: [dita] MUST, SHOULD, and MAY, some key words from RFC
2119
Looks good, Jeff - with the caveat though that even though the core is
MUST and the specializations are RECOMMENDED or OPTIONAL, a specialization
may introduce behavior that overrides the core.
In other words, all behavior, core and specialized, is overrideable.
