[Bug 5151] pseudo-normative qualifications used in apparently normative contexts

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


cmsmcq@w3.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needsDrafting               |needsPublication




------- Comment #5 from cmsmcq@w3.org  2008-05-09 20:48 -------
3 Properties in the PSVI

    Your argument seems "strange" given the context.  Expanding the
    excerpt ever so slightly, in 3.1.1 we find:

        "Any property not defined as optional is always present;
        optional properties which are not present are taken to have
        ·absent· as their value. Any property identified as a having a
        set, subset or list value may have an empty value unless this
        is explicitly ruled out: this is not the same as ·absent·. Any
        property value identified as a superset or subset of some set
        may be equal to that set,"

    Thus, in the already existing text, sentence 1 shies away from RFC
    2119 vocabulary while both of the next two sentences, I think
    describing the same PSVI, use RFC 2119-style MAYs.  This seems
    inconsistent.

Yes, you're right; it is.  I think the error is the use of conformance
language in the sentences containing "may".  But at the moment I do
not have a good reformulation for them.


4 "One of the following"

    ...  3 eyebrow hairs of concern arise at "fairly obvious that the
    items are mutually exclusive", since "fairly obvious" is Eye of
    the Beholder territory.  ...

Point well taken.

    My lowest-cost fix would be to state in 1.5 that in cases where
    the authors believe the list items to be mutually exclusive, [this
    language] has been used.  While the authors are most likely right
    when assessing whether a set of options falls into the ==1, >=1, 0
    or 1 sorts of categories, that is still their assessment (dare I
    say assertion) and hence it may be wrong, however unlikely.

Sometimes I worry that 1.5 is getting kind of crowded, but I think
this works for me.


5 MUST vs "is" or "apply" ...

    We simply  read the suggested words  to  mean different things.  I
    mentally append "in order for the constraint to be met" after each
    of these, which is for most  humans functionally equivalent to "in
    order for the 'thing' to  be valid".  So, for  me, they are  still
    contingent.   If we want  to reduce  this down to  modal logic,  I
    think  by  definition you've just  lost   the  majority of  humans
    (regardless of how correct doing so might be).

I should make clear that I don't believe either that the 1.0 spec
intended the rules to be read in the light of modal logic or that 1.1
should do so.  But I found it impossible to read the nested uses of
MUST without stopping to say "well, this clearly doesn't mean what it
says; as a reader I will have to make allowances for that."  We don't
have a lot of other reports, so maybe I'm the only reader who found it
confusing.  Since the WG made the change, however, either I persuaded
them that it was an improvement or they were just humoring me and must
now see the price to be paid for it.

    Taking the first citation as a concrete example:

        Schema Representation Constraint: Attribute Declaration
        Representation OK In addition to the conditions imposed on
        <attribute> element information items by the schema for schema
        documents, all of the following also apply:

    Cinching down the language lawyer hat, I have to ask what "apply"
    even means. Allowing for a bit more cranial circulation, I think
    the intent is one (or both, to me they are essentially the same)
    of the following:

    (1) In addition to the conditions imposed on <attribute> element
    information items by the schema for schema documents, all of the
    following conditions also are imposed:

    (2) In addition to the conditions imposed on <attribute> element
    information items by the schema for schema documents, all of the
    following conditions also must be tested:

    Either of those would, to me, be an improvement.  I will not lay
    down in the tracks over it however.

I like both of these.

    7 The appropriate case

        "In this case, it's clear on examination that only one of the
        items can be true at a time."

    Kind of you to prove my point for me.  In certain languages with
    "case", an otherwise is ALWAYS executed unless the individual
    when/if tests contain a "break".  It is exactly this potential
    difference in assumptions I was pointing out.

I'm not certain that I understand the issue you are raising here.  I
thought at first that it was "What happens if in a series of "if
<condition> then <result>" items, more than one condition is
satisfied?", which makes a difference in just those lists where the
conditions are not mutually exclusive.  (Hence the reply, which
suggests that the list in question is not really ambiguous.)

But now you're focusing on the "otherwise", which makes me think I
didn't understand the issue here in the first place.

Would rephrasing the boilerplate help?  And if so, then rephrasing it
how?

Or if really the only thing for it is to say explicitly in section 1.5
what this idiom means, then (I'm sorry to be so dense) what exactly do
you believe we should say about it, to make it clearer to readers?

Received on Friday, 9 May 2008 20:49:19 UTC