Re: how should RFC 2119 text be rendered?

This is an excellent test case.

The incumbent conventional wisdom at least in the Protocols and Formats WG
of the WAI is that one should have a clear model of the semantic space
covered, and allow flexible bindings to interface effects to accomodate a
diverse range of delivery contexts.

  http://www.w3.org/TR/2003/WD-WCAG20-20030624/
   http://lists.w3.org/Archives/Public/w3c-wai-ig/2003JulSep/0196.html
  http://www.w3.org/TR/xag

That has two sides to it.  On the one hand, there should be marks or
rule-following in the 'content' encoding to unambiguously distinguish 
between an
instance of the term 'must' where it is intended to mean "per the technical
definition provided in RFC 2119" and instances of the term where it is
intended to mean anything that would be recognized in current common parlance.

On the other hand, style properties can be used to convey this distinction;
but the default should be to follow the precedent in RFC 2119 literally
wherever this reasonably works.  Particularly in Web technology specifications,
it is likely that people will be reading RFCs as well and to use the same sign
(inflection) where the same sense (distinction) is meant is friendly to the
user (specification reader).

The test case effect carries on further, however.

In the XML Accessibility Guidelines we call for traces to be annotated from
schemas underlying the format in use to other authority for the meaning
intended where such prior or peer authority is known.

  http://www.w3.org/TR/xag#cp4_5

Can we, in XSD, define the distinguished semantic atoms "'must' per RFC
2119" and "'must' in common parlance"?  Or do we in XSD define the in-XML
indications of these notions and create the semantic bindings through
liaisons from the schema items to the RFC 2119 notions?

This is a very live matter, as concept-mapping for Terms of Art is a live
issue in the Web Content Accessibility Guidelines working group (Guidelines
3 and 4) and for the PF/Voice exploration of possible specifications in the
lexicon and semantic interpretation area.  For example, find the second
instance of 'lexicon' in:

  http://www.w3.org/Voice/

In summary, PF seeks good examples of documenting the sense of refinements
in XML usage.  RFC 2119 terms are a good and "own dog food" example of the
Terms of Art class of usage.  Further, this is an important example because 
the
case-insensitive matching that is common for dictionary-lookup in English
will fail to distinguish the should-be-distinguished instances of the RFC
2119 terms.  So we need something specific and intentional, whether it is a
rule saying "you have to treat these terms as case sensitive in this
document" or markup on all instances of one or the other semantic variant.

  http://www.w3.org/WAI/PF/usage/languageUsageAndAccess.html
  http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0542.html

Al

At 11:44 AM 2003-08-18, Dominique Hazaël-Massieux wrote:
>(sorry for the long delay to this reply, I meant to reply a long time
>ago).
>
>Le jeu 12/06/2003 à 21:52, pat hayes a écrit :
> > I have a style question regarding how best to render RFC2119 meanings
> > in HTML documents.
> >
> > http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/ section 1.6 says:
> > "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY ", and "OPTIONAL" will be
> > used as defined in RFC 2119 [RFC2119] . When used with the normative
> > RFC2119 meanings, they will be all uppercase. Occurrences of these
> > words in lowercase comprise normal prose usage, with no normative
> > implications. "
>
>Note that this only concerns the usage of RFC keywords in specGL, not
>the usage mandated by specGL for other specifications. The relevant part
>for the latter says:
>"""
>Checkpoint 13.1. Use conformance key words.
>Conformance requirements: the specification MUST use RFC 2119 keywords
>to denote whether or not requirements are mandatory, optional, or
>suggested.
>Rationale: Using these keywords helps to identify the testable
>statements in a specification.
>"""
>http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/#Ck-use-keywords
>
>It does not insist on uppercase/lowercase.
>
> > I would normally understand this to mean that these keywords should
> > appear in a document in visible uppercase. However, section 9.7 of
> > http://www.w3.org/Guide/pubrules  says:
>
>It's actually the Manual of Style [1], not the pubrules. Note that the
>Manual of Style is only a set of guidelines, it's not enforced (nor is
>SpecGL, at least as of today).
>
> > and the recommended styling removes the uppercase from the view of
> > the document as seen in most browsers, so it is impossible for a
> > reader to see whether the word is being used normatively or normally
> > (with emphasis).
>
>The idea is that the emphasis indicates the normativity of the words.
>And the key here is that if you use RFC keywords that way, you will have
>a section of your document that declares it using the same markup, and
>hence the same aspect. Note that the uppercase choice in RFC 2119 is
>related to the regular format of RFC as text/plain, where HTML has much
>more possibilities of expressivity.
>
> > So, which is it? MAY what the reader sees on their screen look like
> > lowercase italic, or MUST it look like uppercase Roman?
>
>It MAY look like lowercase italic, provided that you declare it that way
>(in my understanding). FWIW, the QA WG didn't have any strong consensus
>toward one solution or the other.
>
>Dom
>
>[1] http://www.w3.org/2001/06/manual/#RFC
>--
>Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
>W3C/ERCIM
>mailto:dom@w3.org

Received on Tuesday, 19 August 2003 12:17:14 UTC