Re: Why (IMO) you should vote Yes to Motion 14.02
> Date: Tue, 29 Jun 2010 22:31:08 +0200
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Cc: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Why (IMO) you should vote Yes to Motion 14.02
>
> Zitat von Nate Hayes <nh@xxxxxxxxxxxxxxxxx>:
> >>>
> >>> . . .
> >>
> >
> > I think if you ask the authors of the motion, they will probably disagree
> > with you about this, i.e., the particular wording is specifically designed
> > to rule out mid-rad. I see Ian has already posted a good explanation why.
Nate, you are just wrong here. I can find no kinder way of
putting it.
If you ask THIS author of (a previous version of) the motion
you will find out that the wording is specifically designed to
INCLUDE mid-rad. But it places a non-trivial burden on any
conforming mid-rad form.
And Ian's example, while relevant, does not imply otherwise.
I have explained this several times now.
>
> Well, as I already mailed, this is probably nitpicking. I think the
> actual wording doesn't prevent you from conforming with
> mid-rad---whether it's intended or not. The introduction of
> requirements comes entirely from the represented level 2 datum. The
> motion says "if you accept to work with a certain level 2 datum don't
> approximate it in storage". But we have to sort out the question of
> supported formats to have a solid wording of course.
>
> Cheers,
>
> Christian
Christian is neither nitpicking nor wrong about the intention
of the motion.
The "approximation in storage" IS the issue.
And it is a difficult one.
As for sorting out the nature of supported formats, I think
we would all be well served to ignore the nature of those
formats entirely in the normative text in favor of describing
their behavior only. If we confined all mention of inf-sup or
mid-rad to informative notes & confined our normative text to
making restrictions on how they shall behave, it would be a
better standard for it.
That's not a bad approach now that I think about it.
Let's consider that as a principle in the writing of this
standard.
Yours,
Dan