Re: informal survey - on spec philosophy

On Mon, Mar 26, 2012 at 2:46 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>  On Monday, 26 March 2012 at 21:40, Glenn Adams wrote:
>
> > It has been stated to me that, at least for "open web platform
> standards", the following statement is true and is shared by the majority:
> >
> > "if it isn't written in the spec, it isn't allowed by the spec"
> Can you provide some examples of what you mean? This seems a little out of
> the blue?
>

the spec phrase "associated with" can be interpreted as any of the
following relations [1]:

   - injective and surjective (one-to-one and onto)
   - injective and non-surjective (one-to-one but not onto)
   - non-injective and surjective (not one-to-one but onto)
   - non-injective and non-surjective (not one-to-one and not onto)

[1] http://en.wikipedia.org/wiki/Bijection,_injection_and_surjection

it has been claimed that "associated with" means at least injective and
perhaps also surjective, and that since the spec does not say it can be
non-injective, then the last two could not apply;

my position is that, unless somewhere it is documented what the convention
"associated with" means, that it is (1) ambiguous, and (2) can be
interpreted in any of the above four ways;

this also goes to the issue of whether "if it is not documented in the spec
it is not allowed" applies; my position is that if the spec is ambiguous
(allows for multiple reasonable readings), then it is allowed (even though
that may not have been the author's intent);


> >
> > I happen to disagree with the truth of this, based on my personal
> experience both with spec writing and with implementation/use of specs, but
> I would be curious to see who agrees with this idea or not.
> >
> > The case in point is an instance of a possible ambiguity in a spec
> because a particular assumption/convention is not documented;
> Which one?
>

see above


> > i.e., an assumption that something isn't allowed even though it isn't
> explicitly disallowed. While I agree it is, in general, impossible (or at
> least impractical) to document all disallowances, I do believe it is
> important to document important disallowances, particular when there are
> concerns raised about spec ambiguity.
> >
>
>  I guess it's a case by case thing. But generally, if the spec is written
> with a "not in spec, not allowed" state machine, then it would hold.
>

there are two issues here:

(1) whether the spec is ambiguous or not (permits multiple
interpretations), and
(2) whether there is an unwritten convention (if the spec doesn't say it
then it is not allowed) that applies or not

my position is that ambiguities should be avoided wherever possible and
that important conventions should be documented; further, i'm not sure I
would agree with a convention of "if the spec doesn't say it then it is not
allowed"; or at least, that is the point of this thread, to see what others
think...