[Bug 12573] New: Tweak definition of user option

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12573

           Summary: Tweak definition of user option
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: David_E3@VERIFONE.com
        ReportedBy: cmsmcq@blackmesatech.com
         QAContact: www-xml-schema-comments@w3.org
                CC: cmsmcq@blackmesatech.com


Followon to the wording proposal adopted for bug 8732.

On today's call the WG discussed the definition of 'user option',
which currently reads:

  [Definition:] user option

    A choice left under the control of the user of a processor,
    rather than being fixed for all users or uses of the processor.

    Statements in this specification that "Processors may at user
    option" behave in a certain way mean that processors may provide
    mechanisms to allow users (i.e. invokers of the processor) to
    enable or disable the behavior indicated. Processors which do
    not provide such user-operable controls must not behave in the
    way indicated.

        Note: The normal expectation is that the default setting for
        such options will be to disable the behavior in question,
        enabling it only when the user explicitly requests it. This
        is not, however, a requirement of conformance: if the
        processor's documentation makes clear that the user can
        disable the behavior, then invoking the processor without
        requesting that it be disabled can be taken as equivalent to
        a request that it be enabled.

        Note: Nothing in this specification constrains the manner in
        which processors allow users to control user
        options. Command-line options, menu choices in a graphical
        user interface, environment variables, alternative call
        patterns in an application programming interface, and other
        mechanisms may all be taken as providing user options.

There was agreement, as I understood the sense of the group, that if
the spec defines behavior A as required but adds that "processors
may at user option adopt behavior B", then 

  (1) A processor that doesn't offer any user control of the matter
MUST perform behavior A.

  (2) Only processors which do provide user-operable controls MAY
perform behavior B.

  (3) The normal expectation is that behavior A will be the default
and behavior B will only be adopted if the user exercises a
non-default option.

  (4) Proposition (3) is however not a requirement of conformance;
it's legal for a processor to make B the default and require an
explicit request for behavior A.

  (5) Nothing we can do can prevent a processor from offering some
other behavior C as yet another possibility.

  (6) Offering the user a choice only between behavior B and some
other behavior C is NOT an acceptable design. The user-operable
control MUST make it possible for the user to cause the processor to
perform behavior A.

There was, I believe, general agreement that the current text does
require (1), (2), (3), and (4) with sufficient explicitness, and
that proposition (5) is a fact of life we do not need to dwell on.
Some WG members thought further that the existing text is properly
read as imposing condition (6).  All agreed, however, that it
wouldn't be a bad idea to make condition (6) a little more explicit.

So I propose the following changes to the text we adopted:

- At the end of the second paragraph of the definition, add the
  sentence "Processors which do provide such user-operable controls
  MUST make it possible for the user to disable the optional
  behavior."

- In the first note, change both occurrences of "the behavior" to
  "the optional behavior", and add at the end "It is required,
  however, that it in fact be possible for the user to disable the
  optional behavior."

So the relevant parts of the passage would now read:

    Statements in this specification that "Processors may at user
    option" behave in a certain way mean that processors may provide
    mechanisms to allow users (i.e. invokers of the processor) to
    enable or disable the behavior indicated. Processors which do
    not provide such user-operable controls must not behave in the
    way indicated.  Processors which do provide such user-operable
    controls MUST make it possible for the user to disable the
    optional behavior.

        Note: The normal expectation is that the default setting for
        such options will be to disable the optional behavior in
        question, enabling it only when the user explicitly requests
        it. This is not, however, a requirement of conformance: if
        the processor's documentation makes clear that the user can
        disable the optional behavior, then invoking the processor
        without requesting that it be disabled can be taken as
        equivalent to a request that it be enabled.  It is required,
        however, that it in fact be possible for the user to disable
        the optional behavior.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 29 April 2011 17:14:18 UTC