Re: Normative in UAAG10 (and other W3C TRs)

[blind copies to UA and to XTECH for cross-group specification language
coordination.]

A Very good point.

** summary

Our definition of 'normative' as used in W3C documents should be something
like

[draft]
The term 'normative' [as used in this document] is an adjective indicating "on
which the rules set forth in this document depend for their most precise
statement."
[end draft]

The claimed ISO rule that normative references always include by reference the
whole cited publication is excessive and should not be subscribed to as a
general rule.

The computer science topic of "constraint flow" is the theoretical foundation
on which our policies for distinguishing normative clauses and references
should be based.  In terms of constraint flow,

[theory]
Normative references import constraints.  Normative clauses (as a subset of
all
things said in the current document) [synonyms:] construct, create or impose
constraints.
[end theory]

** details, interleaved

At 10:48 PM 2001-03-10 -0500, Harvey Bingham wrote: 
>
> Summary: 
>
> I suggest a paragraph in UAAG10 giving definition to "Normative" and to 
> either "Informative" or "Non-normative." Some readers won't be familiar 
> with the technical meanings of these words. 
>
> Such paragraph seems useful boilerplate for all WAI Technical 
> Recommendations that use normative.
>
> In UAAG10 need to explain in context how normative applies to checkpoints. 
> I do not find such. Since they are not used within the checkpoints 
> in section 2, the "sometimes normative, sometimes not" qualification 
> from section 3 Conformance can be confusing.
>
> Discussion:
>
> I note that XML refers to  Normative and Non-Normative, but doesn't define 
> them. The ISO convention was Normative and Informative.
>  
> 1. Dictionary searches on normative:
>
> From the Random House dictionary: 
>   "normative, adj, 
>   1. of or pertaining to a norm or standard. 
>   2. tending or attempting to establish such a norm, 
>   exp. by the prescription of rules: normative grammar."
>
> That definition doesn't seem strong enough. 


AG:: it depends on how you apply it.  This distiction is actually enough if
the
strictness comes from the context "of writing a specfication."

In the XML specification, the sense of normative vs. non-normative can be
fully
explained by this dictionary reference, because it is used to distinguish
"that
which sets the rule" from other stuff said.

The fact that the rules are strict and precise comes from the nature of the
XML
specification as defining machine interpretable semantics for "machine
communicable" data.  Not from from the word 'normative' per se.

Our definition of 'normative' as used in W3C documents should be something
like

The term 'normative' is an adjective indicating "on which the rules set forth
herein depend for their most precise statement."

Note:  I agonized about the 'most' in "most precise statement."  But we need a
framework of specification that admits that there may be no "terminally
precise
statement" for some of our rules.  Only "as precise as it gets."  This is
going
to cause friction with some software types who believe that there is a
definitive Boolean domain wherein all our specifications are grounded and
where
all propositions are either true or false, period.

We have to write rules such as "the link text should presage what you will get
if you follow the link."  Here there is no precise machine-interpretable
way to
determine if this normative clause has been satisfied.  That is as precise as
it gets.  But any references required to be expanded to get to that level of
precision are normative references, all the same. 

So, a dependency on an external writing is normative if and only if expanding
the local use of language restricted remotely in conformance with the remotely
stated restrictions will result in a more precise statement of a local rule. 
It is not necessary that the expansion satisfy the "absolute premise" that it
will result in "the precise statement" of the local rule.

Normative references import constraints.  Normative clauses (among the things
said in the current document) [synonyms: construct, create or impose]
constraints.  That's it in a nutshell.


>
> From Webster's Collegiate Dictionary online:
>    
> <http://www.smsu.edu/contrib/library/webwords.html>http://www.smsu.edu/con
> trib/library/webwords.html
>
> Main Entry: nor·ma·tive
> Pronunciation: 'nor-m&-tiv
> Function: adjective
> Etymology: French normatif, from norme norm, from Latin norma
> Date: 1878
>   1 : of, relating to, or determining norms or standards <normative tests>
>   3 : prescribing norms <normative rules of ethics> <normative grammar>
>
> Main Entry: norm
> Pronunciation: 'norm
> Function: noun
> Etymology: Latin norma, literally, carpenter's square
> Date: 1674
>   1 : an authoritative standard : MODEL
>   2 : a principle of right action binding upon the members of a group and 
>       serving to guide, control, or regulate proper and acceptable behavior
>
> 2. Elucidation in the ISO/IEC version of HTML:
>
> User's Guide to ISO/IEC 15445:2000 HyperText Markup Language (HTML)
>    
> <http://www.cs.tcd.ie/15445/UG.html#p.123>http://www.cs.tcd.ie/15445/UG.ht
> ml#p.123
>
>   "NOTE: In an ISO/IEC specification, a normative reference has the effect 
>   of including all the provisions of the referenced text into the
referencing
>
>   text. 
>
>   The W3C Recommendation itself contains normative references, but it is  
>   implicit that the effect is not one of "total normative inclusion". The
W3C
>
>   normative references appear to be closer in spirit to ISO/IEC informative 
>   references defining good practice, and we recommend that they should be 
>   treated as such. "
>
> The ISO clarification is interesting: W3 has watered down the meaning
> of normative. That leaves much to interpretation. Won't lawyers have
> fun arguing at our expense.


AG:: That is interesting indeed.  I would argue that what is claimed in this
remark is an outdated and excessive policy.  It is counter-productive to
consider than any normative reference into a published document requires that
the whole of that document be applied.  It is true that taking statements out
of context can break them, but protecting against such breakage in references
among software specifications by always "eating the whole thing" is excessive
in a way that can be unfortunate.

Well-written specifications are written in language where it is possible to
surgically construct a traceback of dependencies and recognize the subset of
the referenced document on which the current document actually depends.

To me, the definitive relationship is dependencies in the actual clauses in
the
respective documents.  If a normative clause in the current document makes use
of rules whose definitive statement is in the language of the other document,
then there is a [normative, i.e. for the purposes of articulating a rule]
dependency of the current document on the referenced document.  Normative
references in the bibliography are references to documents on which the
current
document depends.  But the current document does not necessarily depend on
everything said in every such document.

The way the language of the cited document works determines how much of the
cited document is actually implicated in the dependency.  For a concrete
example, consider a token defined in an enumeration type such as the 'media'
enumeration type used in HTML4 and CSS2.  The definition of the individual
choice is a function of the alternatives to this choice.  One has to include
the definition of the type in references to this token to have it make sense. 
But it is not necessary to require all of CSS2 in order to use media="screen"
in the same sense as it is used in CSS2.

>
> 3. Clarifications in UAAG10:
>
> I believe that in section 2 early you should indicate that applicable 
> checkpoints are normative (some as qualified in section 3.) Notes are 
> informative. You do only state the latter.
>
> In UAAG10 Section 3. Conformance 
>
>   "This normative section defines what it means to conform to this
document."
>
>
> [Here put meaning of normative (and contrast it with non-normative or
> informative.]
>   
> In it is reference to [RFC 2119]. In that reference there is no mention 
>   of either Normative or Informative. 
>
> In Subsections 5.2 Normative References and 5.3 Informative References
>  
> Normative only applies to References, not to checkpoints. 
>
> 4. Once burned:
>
> 33 years ago I worked on a multi-million dollar proposal effort. We couldn't
> afford the bid, but couldn't afford not to. Our submission was rejected 
> as the design had not considered a requirement indirectly found in the 
> request for proposal to a normative document that itself had a normative 
> reference to yet another document. A costly lesson.
>
> 5. Effect of normative references:
>
> Are we sure that there is nothing in the Normative References
> that can burn any implementor of UAAG10?
>
> Regards/Harvey Bingham
>    

Received on Sunday, 11 March 2001 11:48:09 UTC