Subject: [Ltru] 2nd WG last call: reduce 'could', 'would', 'might'

From: Martin Duerst <[email-masked]>
Date: Tue, 16 May 2006 18:48:44 +0900

[co-chair hat off, for this and following mails, unless explicitly
indicating the contrary]

This is something I have been working on continuously, with not
too much success, but I'm trying it again: There are many
instances where 'might', 'could', or 'would' is used, but isn't necessary.
This is particularly frequent in examples. If something is declared
as an example, there is no need to use conditional language,
it's already prefectly clear that it's just an example.

I hope that with the changes below, the document will read more
like a spec and less like speculation :-).

[sometimes, some other word also needs to be changed, e.g.
from past/conditional to present]

Please change as proposed below:

    Applications, protocols, or specifications, in addressing their
    particular requirements, can offer pre-processing or configuration
    options.  For example, an implementation could allow a user to
    associate or map a particular language range to a different value.

    could -> can

                              Or perhaps the user could associate the
    range "zh-Hans" (Chinese as written in the Simplified script) with
    the language tag "zh-CN" (Chinese as used in China, where the
    Simplified script is predominant) because content is available with
    that tag.

    could -> will (maybe also change 'the user' to 'a user')

    For example, an implementation could return the matching tag that is
    first in ASCII-order.  If the language range were "*-CH" and the set
    of tags included "de-CH", "fr-CH", and "it-CH", then the tag "de-CH"
    would be returned.  Another possibility would be for an
    implementation to map the extended language ranges to basic ranges.

    could -> can, were -> is, included -> includes, would be -> is (two times)

                                 When given as examples in this document,
    language priority lists will be shown as a quoted sequence of ranges
    separated by commas, like this: "en, fr, zh-Hant" (which would be
    read as "English before French before Chinese as written in the
    Traditional script").

    "would be read" -> "is read" (or "reads")

                                      An example of this would be the use
    of "q" values in the syntax of the "Accept-Language" header (defined
    in [RFC2616], Section 14.4, and [RFC3282]).

    "would be" -> "is"

    An extended language range is mapped to a basic language range as
    follows: if the first subtag is a '*' then the entire range is
    treated as "*", otherwise each wildcard subtag is removed.  For
    example, if the language range were "en-*-US", then the range would
    be mapped to "en-US".

    "were" -> "is", "would be" -> "is"

    For example, if a particular user's language priority list were
    "fr-FR, zh-Hant" and the program doing the matching had a default
    language range of "ja-JP", the program would search as follows:

    "were" -> "is", "would search" -> "searches"

    Users SHOULD avoid subtags that add no distinguishing value to a
    language range.  When filtering, the fewer the number of subtags that
    appear in the language range, the more content the range will
    probably match, while in lookup unnecessary subtags might cause
    "better", more-specific content to be skipped in favor of less
    specific content.  For example, the range "de-Latn-DE" would return
    content tagged "de" instead of content tagged "de-DE", even though
    the latter is probably a better match.

    might -> can, would -> will

                      For example, if a process were to insert a human
    readable error message into a protocol header, it might select the
    text based on the user's language priority list.  Since the process
    can return only one item, it must choose a single item and it must
    return some item, even if none of the content's language tags match
    the language priority list supplied by the user.

    were to insert -> inserts, might select -> can select

    The wildcard subtag '*' can occur in any position in the extended
    language range, where it matches any sequence of subtags that might
    occur in that position in a language tag.

    might occur -> occur

    Filtering can be used to produce a set of results (such as a
    collection of documents) by comparing the user's preferences to a set
    of language tags.  For example, when performing a search, one might
    use filtering to limit the results to items tagged as being in the
    French language.  Filtering can also be used when deciding whether to
    perform a language-sensitive process on some content.  For example, a
    process might cause paragraphs whose language tag matched the
    language range "nl" to be displayed in italics within a document.

    might -> can (two times), matched -> match

    Lookup produces the single result that best matches the user's
    preferences from the list of available tags, so it is useful in cases
    in which a single item is required (and for which only a single item
    can be returned).  For example, if a process were to insert a human
    readable error message into a protocol header, it might select the
    text based on the user's language priority list.  Since the process
    can return only one item, it must choose a single item and it must
    return some item, even if none of the content's language tags match
    the language priority list supplied by the user.

    were to insert -> inserts, might select -> selects

    o  For lookup, what the default item is (or the sequence of
       operations or configuration information used to determine the
       default) when no matching tag is found.  For instance, a protocol
       might define the result as failure of the operation, an empty
       value, returning some protocol defined or implementation defined
       default, or returning i-default [RFC2277].

     might -> can

    Some examples of applications where filtering might be appropriatd sequence of ranges
    separated by commas, like this: "en, fr, zh-Hant" (which would be
    read as "English before French before Chinese as written in the
    Traditional script").

    "would be read" -> "is read" (or "reads")

                                      An example of this would be the use
    of "q" values in the syntax of the "Accept-Language" header (defined
    in [RFC2616], Section 14.4, and [RFC3282]).

    "would be" -> "is"

    An extended language range is mapped to a basic language range as
    follows: if the first subtag is a '*' then the entire range is
    treated as "*", otherwise each wildcard subtag is removed.  For
    example, if the language range were "en-*-US", then the range would
    be mapped to "en-US".

    "were" -> "is", "would be" -> "is"

    For example, if a particular user's language priority list were
    "fr-FR, zh-Hant" and the program doing the matching had a default
    language range of "ja-JP", the program would search as follows:

    "were" -> "is", "would search" -> "searches"

    Users SHOULD avoid subtags that add no distinguishing value to a
    language range.  When filtering, the fewer the number of subtags that
    appear in the language range, the more content the range will
    probably match, while in lookup unnecessary subtags might cause
    "better", more-specific content to be skipped in favor of less
    specific content.  For example, the range "de-Latn-DE" would return
    content tagged "de" instead of content tagged "de-DE", even though
    the latter is probably a better match.

    might -> can, would -> will

                      For example, if a process were to insert a human
    readable error message into a protocol header, it might select the
    text based on the user's language priority list.  Since the process
    can return only one item, it must choose a single item and it must
    return some item, even if none of the content's language tags match
    the language priority list supplied by the user.

    were to insert -> inserts, might select -> can select

    The wildcard subtag '*' can occur in any position in the extended
    language range, where it matches any sequence of subtags that might
    occur in that position in a language tag.

    might occur -> occur

    Filtering can be used to produce a set of results (such as a
    collection of documents) by comparing the user's preferences to a set
    of language tags.  For example, when performing a search, one might
    use filtering to limit the results to items tagged as being in the
    French language.  Filtering can also be used when deciding whether to
    perform a language-sensitive process on some content.  For example, a
    process might cause paragraphs whose language tag matched the
    language range "nl" to be displayed in italics within a document.

    might -> can (two times), matched -> match

    Lookup produces the single result that best matches the user's
    preferences from the list of available tags, so it is useful in cases
    in which a single item is required (and for which only a single item
    can be returned).  For example, if a process were to insert a human
    readable error message into a protocol header, it might select the
    text based on the user's language priority list.  Since the process
    can return only one item, it must choose a single item and it must
    return some item, even if none of the content's language tags match
    the language priority list supplied by the user.

    were to insert -> inserts, might select -> selects

    o  For lookup, what the default item is (or the sequence of
       operations or configuration information used to determine the
       default) when no matching tag is found.  For instance, a protocol
       might define the result as failure of the operation, an empty
       value, returning some protocol defined or implementation defined
       default, or returning i-default [RFC2277].

     might -> can

    Some examples of applications where filtering might be appropriate
    include:

    might -> can (or will?)

    For example, if an application inserts some dynamic content into a
    document, returning an empty string if there is no exact match is not
    an option.  Instead, the application "falls back" until it finds a
    matching language tag associated with a suitable piece of content to
    insert.  Examples of lookup might include:

    might include -> include

    Extensions and unrecognized private-use subtags might be unrelated to
    a particular application of lookup.  Since these subtags come at the
    end of the subtag sequence, they are removed first during the
    fallback process and usually pose no barrier to interoperability.

    might be -> can be

                                    Such modification is internal to the
    implementation and applications, protocols, or specifications SHOULD
    NOT remove or modify subtags in content that they return or forward,
    because this removes information that might be used elsewhere.

    might be -> can be

    In some cases, the language priority list might contain one or more
    extended language ranges (as, for example, when the same language
    priority list is used as input for both lookup and filtering
    operations).

    might contain -> can contain

    Each application, protocol, or specification MUST define the
    defaulting behavior when no tag matches the language priority list.
    What this action consists of strongly depends on how lookup is being
    applied.  Some examples of defaulting behavior might include:

    might include -> include

    The default value MAY be calculated and might include additional
    searching or matching.  Applications, protocols, or specifications
    can specify different ways in which users can specify or override the
    defaults.

    might -> can

    Applications are encouraged to canonicalize language tags and ranges
    by using the Preferred-Value from the IANA Language Subtag Registry
    for tags or subtags which have been deprecated.  If the user is
    working with content that might use the older form, the user might
    want to include both the new and old forms in a language priority
    list.  For example, the tag "art-lojban" is deprecated.  The subtag
    'jbo' is supposed to be used instead, so the user might use it to
    form the language range.  Or the user might include both in a
    language priority list: "jbo, art-lojban".

    four 'might' in a single paragraph, please reduce

    Users SHOULD avoid subtags that add no distinguishing value to a
    language range.  When filtering, the fewer the number of subtags that
    appear in the language range, the more content the range will
    probably match, while in lookup unnecessary subtags might cause
    "better", more-specific content to be skipped in favor of less
    specific content.

    might -> can

    Whether a subtag adds distinguishing value can depend on the context
    of the request.  For example, a user who reads both Simplified and
    Traditional Chinese, but who prefers Simplified, might use the range
    "zh" for filtering (matching all items that user can read) but "zh-
    Hans" for lookup (making sure that user gets the preferred form if
    it's available, but the fallback to "zh" will still work).  On the
    other hand, content in this case should be labeled as "zh-Hans" (or
    "zh-Hant" if that applies) for filtering, but for lookup, if there is
    either "zh-Hans" content or "zh-Hant" content, then one of them (the
    one considered 'default') should also be available under a simple
    "zh".

    might use -> can use
    There is also a lower-case should, which we should remove.
    Maybe write "preferably also is made available under a simple "zh"."

Regards,     Martin. 

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Tue, 16 May 2006 09:02:47 -0400

Martin Duerst scripsit:

-1.  Not clear why on this one either.

> Please change as proposed below:

Some of these changes generate forms that, to a native anglophone
ear, are unnatural English.  Anything I don't mention here, I approve of
without comment.

>    could -> will (maybe also change 'the user' to 'a user')

Unnatural.  Better:  "a user will want to"

>    could -> can, were -> is, included -> includes, would be -> is (two 

-1.  This should be left firmly conditional.

>    "would be read" -> "is read" (or "reads")

+1.  "is read" is preferable.

>    "were" -> "is", "would be" -> "is"

+1 in principle.  Better:  'For example, a language range of "en-*-US"
is mapped to "en-US".'

>    might -> can (two times), matched -> match

"Match" would be outright ungrammatical, but "matches" works.
I doubt this is worth changing.  +1 on might -> can.

>       default, or returning i-default [RFC2277].

-1.  This should be left alone for reasons I can't quite explain (a
matter of Sprachgefuehl).

>    Some examples of applications where filtering might be appropriate

-1.  This should definitely be left alone.  Both "can" and "will" are
too strong.

>    insert.  Examples of lookup might include:

Better:  "Possible applications of lookup include:"

>    fallback process and usually pose no barrier to interoperability.

-1.  That changes meaning.

>    because this removes information that might be used elsewhere.

+1, even though this too changes meaning.

>    four 'might' in a single paragraph, please reduce

I think the last can be changed to "can include", but the rest should
stand: the first one is about a speculation (on what exists in the
unsearched data); the second and third express mere possibility
and would be "may" if that word weren't effectively pre-empted.

>    one considered 'default') should also be available under a simple

-1.  This is mere possibility, so "might" is appropriate (see above).

>    Maybe write "preferably also is made available under a simple "zh"."

-1.  That is very clunky.  I propose "ought also to be available".

-- 
It was impossible to inveigle           John Cowan <[email-masked]>
Georg Wilhelm Friedrich Hegel           http://www.ccil.org/~cowan
Into offering the slightest apology
For his Phenomenology.                      --W. H. Auden, from "People" (1953)

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 16 May 2006 13:07:16 -0700

As usual, Martin, thank you for an excellent close reading of the document.
Comments follow.

~Addison

> it's already prefectly clear that it's just an example.

I'm not entirely happy to implement lots of editorial changes that make no
difference. 

It seems that I use more of the "subjunctive mood" in my writing than most.
In some cases, you'll have to live with it :-).
>     associate or map a particular language range to a different value.

I disagree. This is a speculative example.
>     could -> will (maybe also change 'the user' to 'a user')

Ditto.
>     could -> can, were -> is, included -> includes, would be -> is (two

I disagree. I don't want to make this example anything less that
suppositional.
>     "would be read" -> "is read" (or "reads")

Done.
>     in [RFC2616], Section 14.4, and [RFC3282]).

Done.
>     "were" -> "is", "would be" -> "is"

'For example, the extended language range "en-*-US" maps to "en-US".'

Nice to see that John Cowan's edit matched mine.
>     "were" -> "is", "would search" -> "searches"

Done.
>     might -> can, would -> will

Done, with some minor differences.
>     were to insert -> inserts, might select -> can select

I don't think the changes would be correct.
>     occur in that position in a language tag.

Ditto.
>     might -> can (two times), matched -> match

For the first might->can, I chose to rewrite instead (to be in keeping with
the form of the other sentences):

--
For example, when performing a search, filtering can be used to limit the
results to items tagged as being in the French language.
--

I really don't want to change the second "might".
>     were to insert -> inserts, might select -> selects

This is an excellent example of the subjunctive in action. Changing it as
you ask would make the example too definite.
>        default, or returning i-default [RFC2277].

Nope. For the reason John Cowan gave ("for instance" signals that these are
examples from a larger list. I could say "can", but that is somehow too
definite....)
>     Some examples of applications where filtering might be appropriate

Not done. This is an incomplete list of appropriate applications. No reason
to make it more definite.
>     insert.  Examples of lookup might include:

I wrote:

--
Some applications of lookup include:
--
>     fallback process and usually pose no barrier to interoperability.

No, for the reason John Cowan gave: it changes the meaning.
>     because this removes information that might be used elsewhere.

Done.
>     might contain -> can contain

Done.
>     applied.  Some examples of defaulting behavior might include:

Done.
>     can specify different ways in which users can specify or override the

I rewrote this sentence slightly, making use of both the normative meaning
of "MAY" and the English meaning of "may":

--
The default value MAY be calculated or include additional searching or
matching.
--
>     four 'might' in a single paragraph, please reduce

John Cowan spelled out the reasoning behind the conditional text here. It
all stems from the first 'might'...
>     "better", more-specific content to be skipped in favor of less

Done.
>     one considered 'default') should also be available under a simple

No, this is supposition.

>     Maybe write "preferably also is made available under a simple "zh"."
Actually, there are two lowercase 'shoulds'. I changed the sentence to:

--
On the other hand, content in this case ought to be
    labeled as "zh-Hans" (or "zh-Hant" if that applies) for filtering,
    while for lookup, if there is either "zh-Hans" content or "zh-Hant"
    content, one of them (the one considered 'default') also ought to be
made available with the simple "zh".
--