But that wouldn't address my concern. This isn't a
normative versus informative issue.
I'm saying that the DITA spec itself isn't the place to
define this, so using shoulds and mays isn't any better than
musts.
My point exactly is that implementations aren't going to do
anything about sorting, and users shouldn't expect anything about sorting, since
we aren't talking about sorting in the DITA spec, at least not in DITA
1.2.
We're just adding an element to be a place to provide
information that could be used by some non-DITA-standardized process.
Whatever that process is--unless the TC agrees to get into defining sorting in
DITA 1.2 (and even then, we'd probably never define all the uses one might
reasonably want to make of collate-as)--has to be defined somewhere else.
paul
From:
[mailto:]
Sent: Tuesday, 2007 August 28
17:55
To: Grosso, Paul
Cc:
Subject: RE: [dita] Groups - Proposal
#12035: Generic collation element
Hi Paul,
I see where you're coming from, and I think I agree
with you, but...
If a standard is
to be of use to implementors, there needs to be some explanation about
expected processing, otherwise it can happen that there isn't enough context
for implementors to understand what the feature is for.
Other standards manage this by using RFC 2119's MAY,
SHOULD, MUST, etc., stating that "This section is normative" or "This section
is informative". It doesn't seem that DITA 1.1 does this (yet).
I'm happy to tag the normative vs.
informative bits for #12035 if people think that it's worthwhile.
--
Deborah Pickett
Information
Architect, Moldflow Corporation,
Melbourne
"Grosso, Paul"
<>
08/29/2007 03:12 AM
To
<>
cc
Subject
RE: [dita] Groups - Proposal
#12035: Generic collation element
>
