Re: Informative components of w3c specifications

Like I said earlier, I don't disagree with you Marcos.  Easy enough to fix
if there are complaints from users and we determine there is a need at some
point in the future.

Steven, which particular feature were you thinking should be optional?
 Adding a role of note or adding the informative notation to the Note title?

P.S.  Here is the text from the ANSI C standard (1990) that I tried to
correct.  It was bugging me so I found my notes:

(section 7.7.2.1 on the raise function)

If the signal occurs other than as the result of calling the abort or raise
> function, the behavior is undefined if the signal handler calls any
> function in the standard library other than the signal function itself
> (with the first argument of the signal number corresponding to the signal
> that cause the invocation of the handler) or refers to any object with
> static storage duration other than by assigning a value to a static storage
> duration variable of type volatile sig_atomic_t.  Furthermore, if such a
> call to the signal function results in a SIG_ERR return, the value errno is
> indeterminate.






On Fri, Jul 11, 2014 at 10:57 AM, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On Friday, July 11, 2014 at 10:53 AM, Shane McCarron wrote:
>
> > Marcos, I do *not* disagree with you, but your statement reminded me of
> one of my very early experiences in the standards world. I share it for
> your amusement, but it may also change your mind.
> >
> > I was working on X3J11 (ANSI C) in about 1986?
> Much respect.
> > In reviewing a draft, there was some language that was overly complex
> and honestly unclear. I'm a smart guy and a native English speaker, so I
> finally puzzled it out. But non-native speakers or people who can't readily
> parse a 100 word sentence might have trouble. I proposed a change to
> basically split up the sentence and remove some punctuation so there were
> fewer dependent clauses.
> >
> > A few months later, when the committee was done processing all of the
> change requests, the reply I got was along the lines of "Thank you for your
> comment. Your proposed change is rejected. A complete reading of the
> standard would render full understanding of this issue".
> >
> > In other words, if I read the entire document, I would have known what
> that section meant. I didn't need to be reworded.
> That's very sad to hear. The committee were either incompetent or lacked
> judgement when rejecting your change (specially if it helped clarify
> things).
>
> However, your change was still to normative text. And although I take your
> point about not needing to backtrack to know what is informative and what
> is normative, this still doesn't strengthen (in my mind, at least) the need
> to add "this is informative" explicitly on a note.
> > People don't read the entire document. Other documents link into our
> specs - to sections that have normative text and embedded notes. I am as
> lazy as the next guy. I am not going to scroll up to the conformance
> section to see whether notes are by default informative in the spec I am
> reading at the moment. I'm just not.
>
> Personally, I'm still not convinced that this is an issue. Unlike other
> consortia, we have a strong culture of being very developer focused.
>
> My gut reaction here is that I sometimes feel like we are trying to "fix"
> things preemptively without data to show there is actually a problem.
>