Best practice for referring to specifications which may update

[Henry S. Thompson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the context of an extended discussion at the recent TAG f2f
regarding references to potential time-varying specification URIs [1]
I took an action [2] to suggest wording for a Best Practice in this
area, based on wording developed by C. M. Sperberg-McQueen, who also
reviewed and contributed to the following.

Here's what I think this might look like:

  When citing a W3C specification in the normative references section
  of another specification, care should be taken to be clear about the
  status of editions of the referenced specification other than the
  then-current one.  In order to on the one hand acknowledge that
  implementations sometimes lag behind specifications, and on the
  other that implementations of new editions of referenced
  specifications should be encouraged, wording along the following
  lines should be used:

    Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
    Peter Schickele, Editors.  World Wide Consortium, 29 February
    2009.  The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/)
    is the earliest appropriate for use with this specification.
    Conformant implementations may follow the edition cited and/or any
    later edition(s).  The latest edition of LHSF 1.0 is available at
    http://www.w3.org/TR/lhsf/.  It is implementation-defined which
    editions of LHSF 1.0 are supported.

  The appropriateness of this approach is based on the W3C rules
  regarding what constitutes an acceptable new edition of an existing
  W3C Recommendation.  For references to publications from other
  standards bodies with similar expectations regarding backwards
  compatibility, for example IETF or ISO, a similar approach to
  citation is also called for, along the following lines:

    The Extension of MIME Content-Types to a New Medium, N. Borenstein
    and M. Linimon.  Internet Engineering Task Force RFC 1437, 1 April
    1993.  RFC 1437 was current at the date of publication of this
    specification, but may be updated or obsoleted by later RFCs.
    Conformant implementations may follow the RFC cited and/or any
    later RFCs which update or obsolete it.  It is
    implementation-defined which RFCs are supported.

    Intelligent transport systems -- Physical characterisation of
    vehicles and equipment -- International airline seat pitch
    measurements. Part 1: Measurement architecture.  International
    Standard ISO 314159-1:2009, 29 February 2009.  The referenced
    specification may from time to time be amended, replaced by a new
    edition, or expanded by the addition of new parts.  See
    http://www.iso.org/iso/home.htm for up-to-date information.
    Conformant implementations may follow the edition cited and/or any
    amendments etc.  It is implementation-defined which amendments
    etc. are supported.

  In cases where many references require similar treatment, a blanket
  statement at the top of the references section may be more
  appropriate:

    Dated references below are to the earliest known or appropriate
    edition of the referenced work.  The referenced works may be
    subject to revision, and conformant implementations may follow,
    and are encouraged to investigate the appropriateness of
    following, some or all more recent editions or replacements of the
    works cited.  It is in each case implementation-defined which
    editions are supported.

   and then simply

    Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
    Peter Schickele, Editors.  World Wide Consortium, 29 February 2009
    (http://www.w3.org/TR/2009/REC-lhsf-20090229/).  The latest
    edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/.

    The Extension of MIME Content-Types to a New Medium, N. Borenstein
    and M. Linimon.  Internet Engineering Task Force RFC 1437, 1 April
    1993.

    Intelligent transport systems -- Physical characterisation of
    vehicles and equipment -- International airline seat pitch
    measurements. Part 1: Measurement architecture.  International
    Standard ISO 314159-1:2009, 29 February 2009.  See
    http://www.iso.org/iso/home.htm for up-to-date information.

  All of the above formulations assume a definition of
  'implementation-dependent' along the following lines:

    If a choice is described as 'implementation-dependent', then
    conformant implementations must document which choice they make.

Comments welcome.

ht

[1] http://www.w3.org/2001/tag/2009/09/23-minutes#item03
[2] http://www.w3.org/2001/tag/group/track/actions/303
- --
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: ht@...
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFK6FvskjnJixAXWBoRAkMoAJwLt6r3r+Vv0Bafj7VXG3lTwTUZCQCbBUQt
vLwTcIIeuu0opUPciRUtZ/g=
=TIg8
-----END PGP SIGNATURE-----

[noah_mendelsohn]

Henry Thompson writes:

> Comments welcome.

I think this is good for the common case where you >do< want to
future-proof your references, as in:

"Conformant implementations may follow the edition cited and/or any later
edition(s). "

I do think it would be a step too far for the TAG to imply or require that
such language be used in all cases.  I can easily imagine cases in which
what's desired is to specifically require use of the "edition cited", or
else to allow only later editions meeting certain criteria.  So:

> When citing a W3C specification in the normative references
> section of another specification, care should be taken to be
> clear about the status of editions of the referenced
> specification other than the then-current one.

This should be the binding recommendation from the TAG, and perhaps should
be rephrased using MUST.

> In order to on the one hand acknowledge that
>   implementations sometimes lag behind specifications, and on the
>   other that implementations of new editions of referenced
>   specifications should be encouraged, wording along the following
>   lines should be used:

I might prefer:

--------
"It is often, but not always, good practice to encourage use of new
editions of referenced specifications.  In that common case, wording along
the following lines is recommended:

        (this is unchanged from Henry's)
    Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
    Peter Schickele, Editors.  World Wide Consortium, 29 February
    2009.  The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/
)
    is the earliest appropriate for use with this specification.
    Conformant implementations may follow the edition cited and/or any
    later edition(s).  The latest edition of LHSF 1.0 is available at
    http://www.w3.org/TR/lhsf/.  It is implementation-defined which
    editions of LHSF 1.0 are supported.

Note that this wording also accounts for the fact that implementations
sometimes lag behind specifications."
--------

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








ht@... (Henry S. Thompson)
Sent by: www-tag-request@...
10/28/2009 10:57 AM
 
        To:     www-tag@...
        cc:     "C. M. Sperberg-McQueen" <cmsmcq@...>, (bcc:
Noah Mendelsohn/Cambridge/IBM)
        Subject:        Best practice for referring to specifications
which may update


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the context of an extended discussion at the recent TAG f2f
regarding references to potential time-varying specification URIs [1]
I took an action [2] to suggest wording for a Best Practice in this
area, based on wording developed by C. M. Sperberg-McQueen, who also
reviewed and contributed to the following.

Here's what I think this might look like:

  When citing a W3C specification in the normative references section
  of another specification, care should be taken to be clear about the
  status of editions of the referenced specification other than the
  then-current one.  In order to on the one hand acknowledge that
  implementations sometimes lag behind specifications, and on the
  other that implementations of new editions of referenced
  specifications should be encouraged, wording along the following
  lines should be used:

    Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
    Peter Schickele, Editors.  World Wide Consortium, 29 February
    2009.  The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/
)
    is the earliest appropriate for use with this specification.
    Conformant implementations may follow the edition cited and/or any
    later edition(s).  The latest edition of LHSF 1.0 is available at
    http://www.w3.org/TR/lhsf/.  It is implementation-defined which
    editions of LHSF 1.0 are supported.

  The appropriateness of this approach is based on the W3C rules
  regarding what constitutes an acceptable new edition of an existing
  W3C Recommendation.  For references to publications from other
  standards bodies with similar expectations regarding backwards
  compatibility, for example IETF or ISO, a similar approach to
  citation is also called for, along the following lines:

    The Extension of MIME Content-Types to a New Medium, N. Borenstein
    and M. Linimon.  Internet Engineering Task Force RFC 1437, 1 April
    1993.  RFC 1437 was current at the date of publication of this
    specification, but may be updated or obsoleted by later RFCs.
    Conformant implementations may follow the RFC cited and/or any
    later RFCs which update or obsolete it.  It is
    implementation-defined which RFCs are supported.

    Intelligent transport systems -- Physical characterisation of
    vehicles and equipment -- International airline seat pitch
    measurements. Part 1: Measurement architecture.  International
    Standard ISO 314159-1:2009, 29 February 2009.  The referenced
    specification may from time to time be amended, replaced by a new
    edition, or expanded by the addition of new parts.  See
    http://www.iso.org/iso/home.htm for up-to-date information.
    Conformant implementations may follow the edition cited and/or any
    amendments etc.  It is implementation-defined which amendments
    etc. are supported.

  In cases where many references require similar treatment, a blanket
  statement at the top of the references section may be more
  appropriate:

    Dated references below are to the earliest known or appropriate
    edition of the referenced work.  The referenced works may be
    subject to revision, and conformant implementations may follow,
    and are encouraged to investigate the appropriateness of
    following, some or all more recent editions or replacements of the
    works cited.  It is in each case implementation-defined which
    editions are supported.

   and then simply

    Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
    Peter Schickele, Editors.  World Wide Consortium, 29 February 2009
    (http://www.w3.org/TR/2009/REC-lhsf-20090229/).  The latest
    edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/.

    The Extension of MIME Content-Types to a New Medium, N. Borenstein
    and M. Linimon.  Internet Engineering Task Force RFC 1437, 1 April
    1993.

    Intelligent transport systems -- Physical characterisation of
    vehicles and equipment -- International airline seat pitch
    measurements. Part 1: Measurement architecture.  International
    Standard ISO 314159-1:2009, 29 February 2009.  See
    http://www.iso.org/iso/home.htm for up-to-date information.

  All of the above formulations assume a definition of
  'implementation-dependent' along the following lines:

    If a choice is described as 'implementation-dependent', then
    conformant implementations must document which choice they make.

Comments welcome.

ht

[1] http://www.w3.org/2001/tag/2009/09/23-minutes#item03
[2] http://www.w3.org/2001/tag/group/track/actions/303
- --
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: ht@...
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged
spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFK6FvskjnJixAXWBoRAkMoAJwLt6r3r+Vv0Bafj7VXG3lTwTUZCQCbBUQt
vLwTcIIeuu0opUPciRUtZ/g=
=TIg8
-----END PGP SIGNATURE-----

[C. M. Sperberg-McQueen-2]

On 28 Oct 2009, at 09:20 , noah_mendelsohn@... wrote:

> Henry Thompson writes:
>
>> Comments welcome.
>
> I think this is good for the common case where you >do< want to
> future-proof your references, as in:
>
> "Conformant implementations may follow the edition cited and/or any  
> later
> edition(s). "
>
> I do think it would be a step too far for the TAG to imply or  
> require that
> such language be used in all cases.  I can easily imagine cases in  
> which
> what's desired is to specifically require use of the "edition  
> cited", or
> else to allow only later editions meeting certain criteria.

I think the notion that there might be exceptions is implicit in the
concept of "best practice", so Noah seems to be fighting a straw man
when he suggests that Henry's wording implies a requirement that the
language he lays out must be used in all cases.  He certainly
doesn't seem to be engaging with the proposal actually made.

There may be a real disagreement here, on how strongly the TAG
should recommend loose coupling.  Noah's language suggests he would
rather the TAG be neutral on the matter.  I think that neutrality
would be a mistake: loose coupling is an important architectural
principle.  The TAG should recommend that WGs provide for loose
coupling of their specs to their dependencies in all cases where
they do not have very compelling reasons to do otherwise.

On a minor point: Noah is right to suggest that it would be useful
for referring specs to identify concretely which aspects of the
specs they refer to are essential and which are inessential, so that
it's clear when a later version can be used without contradicting
basic assumptions in the referring spec.  I'm not sure such lists
are likely to be easy or popular, though.  An early draft of WSDL,
for example, was exemplary in describing which aspects of XML and
XSD it depended on, and which could be changed in later versions of
XML and XSD without causing problems for the WSDL spec or for
conforming WSDL implementations.  Unfortunately, all that material
was later excised as unnecessarily complicated, during an attempt to
mollify critics by simplifying the spec.

In the absence of such explicit lists of crucial assumptions about
the specs referred to, I think a blanket permission to use later
versions of those specs is still usually safe by default: if the
later version of the other spec contradicts fundamental assumptions
of the referring spec, then any implementation that attempts to use
the later version will encounter logical contradictions in its terms
of reference, and will find it impossible to use the later version
of the other spec.  If the use of the later spec is logically
impossible, then explicitly prohibiting its use has no benefit for
interoperability.  On the other hand, if using the later spec does
not lead to contradictions, then there is definite harm in
forbidding its use.

It would be ironic for W3C specs to be more conservative and less
flexible in this regard than those of ISO.

--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

[noah_mendelsohn]

Michael Sperberg-McQueen writes:

> There may be a real disagreement here, on how strongly the TAG
> should recommend loose coupling.  Noah's language suggests he would
> rather the TAG be neutral on the matter.

I'm somewhat head down trying to finish a TPAC presentation, so won't
respond to all your other points just now.  On the above, that's not quite
my recommendation for a TAG position.  What I intended to suggest was:

"Loose coupling (or future proofing) is typically good practice and is
generally encourged.  The TAG does recognize that there may be situations
in which such loose coupling is dangerous or just less effective than
tighter coupling, so this is guideline, not a requirement."  So, not
neutral.

> I think the notion that there might be exceptions is implicit in the
> concept of "best practice", so Noah seems to be fighting a straw man
> when he suggests that Henry's wording implies a requirement that the
> language he lays out must be used in all cases.

That's probably the main source of confusion.  Strictly speaking, I
suppose you're right that calling it a "best practice" leaves wiggle room,
but my preference would be for being  a little clearer about it.  I've
observed that even best practice statements by the TAG tend to be wielded
as cudgels when convenient for one party or another, so I tend to err on
the side of being extra-clear as to how strong our recommendations are.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"C. M. Sperberg-McQueen" <cmsmcq@...>
10/28/2009 12:04 PM
 
        To:     noah_mendelsohn@...
        cc:     "C. M. Sperberg-McQueen" <cmsmcq@...>,
ht@... (Henry S. Thompson), www-tag@...
        Subject:        Re: Best practice for referring to specifications
which may update



On 28 Oct 2009, at 09:20 , noah_mendelsohn@... wrote:

> Henry Thompson writes:
>
>> Comments welcome.
>
> I think this is good for the common case where you >do< want to
> future-proof your references, as in:
>
> "Conformant implementations may follow the edition cited and/or any
> later
> edition(s). "
>
> I do think it would be a step too far for the TAG to imply or
> require that
> such language be used in all cases.  I can easily imagine cases in
> which
> what's desired is to specifically require use of the "edition
> cited", or
> else to allow only later editions meeting certain criteria.

I think the notion that there might be exceptions is implicit in the
concept of "best practice", so Noah seems to be fighting a straw man
when he suggests that Henry's wording implies a requirement that the
language he lays out must be used in all cases.  He certainly
doesn't seem to be engaging with the proposal actually made.

There may be a real disagreement here, on how strongly the TAG
should recommend loose coupling.  Noah's language suggests he would
rather the TAG be neutral on the matter.  I think that neutrality
would be a mistake: loose coupling is an important architectural
principle.  The TAG should recommend that WGs provide for loose
coupling of their specs to their dependencies in all cases where
they do not have very compelling reasons to do otherwise.

On a minor point: Noah is right to suggest that it would be useful
for referring specs to identify concretely which aspects of the
specs they refer to are essential and which are inessential, so that
it's clear when a later version can be used without contradicting
basic assumptions in the referring spec.  I'm not sure such lists
are likely to be easy or popular, though.  An early draft of WSDL,
for example, was exemplary in describing which aspects of XML and
XSD it depended on, and which could be changed in later versions of
XML and XSD without causing problems for the WSDL spec or for
conforming WSDL implementations.  Unfortunately, all that material
was later excised as unnecessarily complicated, during an attempt to
mollify critics by simplifying the spec.

In the absence of such explicit lists of crucial assumptions about
the specs referred to, I think a blanket permission to use later
versions of those specs is still usually safe by default: if the
later version of the other spec contradicts fundamental assumptions
of the referring spec, then any implementation that attempts to use
the later version will encounter logical contradictions in its terms
of reference, and will find it impossible to use the later version
of the other spec.  If the use of the later spec is logically
impossible, then explicitly prohibiting its use has no benefit for
interoperability.  On the other hand, if using the later spec does
not lead to contradictions, then there is definite harm in
forbidding its use.

It would be ironic for W3C specs to be more conservative and less
flexible in this regard than those of ISO.

--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

[Karl Dubost-3]

Le 28 oct. 2009 à 10:57, Henry S. Thompson a écrit :
> In the context of an extended discussion at the recent TAG f2f
> regarding references to potential time-varying specification URIs [1]


I encourage you to read the section 2.2.3 Normative (and Non-
Normative) References
http://www.w3.org/TR/qaframe-spec/#reference

The Good Practice 8 specifically.


On Wed, 10 Aug 2005 12:30:15 GMT
In QA Framework: Specification Guidelines
At http://www.w3.org/TR/qaframe-spec/#ref-define-practice

Good Practice 8: When imposing requirements by
normative references, address conformance
dependencies.

What does it mean? Each addition of a normative
reference to the specification has deep
implications on the technology. Specification
editors are responsible for reviewing the
consequences in terms of consistency, precision,
possible future changes or obsolescence as well as
use of the technology under specific conditions.

Why care? A specification defines a technology
with a potentially long lifespan. The choice of
precise and exact normative references is thus
fundamental. Using a normative reference that
evolves over time might endanger the specification
or other specifications relying on it. A vague
reference to the other specification as a whole
may leave room for conflicting interpretations or
choices among variations permitted by the other
specification.

For the Working Group, reducing the degree of
ambiguity or variation in the normative references
minimizes or removes the possibility of
misunderstanding. For implementers, it removes
ambiguities and contradictions between different
sets of technologies. It creates a stable
environment for their development efforts.

For conformance testing to be practical, all
requirements need to be unambiguous, including
those imposed by normative reference to other
specifications.




--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/

[Paul Cotton]

> All of the above formulations assume a definition of
> 'implementation-dependent' along the following lines:

> If a choice is described as 'implementation-dependent', then
> conformant implementations must document which choice they make.

Editorial comment:

Given that all the formulations actually use the phrase "implementation-defined" and not "implementation-dependent", I believe the above text should replace "implementation-dependent" with "implementation-defined".

> conformant implementations must document which choice they make.

I am not sure there is a clear definition of what a "conformant implementation" is in many W3C Recommendations.  Couldn't you simply drop the word "conformant" from each occurrence of "conformant implementation" everywhere it occurs in your proposal without any impact?  

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: [phone] Fax: [phone]

[Henry S. Thompson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Cotton writes:

>> All of the above formulations assume a definition of
>> 'implementation-dependent' along the following lines:
>
>> If a choice is described as 'implementation-dependent', then
>> conformant implementations must document which choice they make.
>
> Editorial comment:
>
> Given that all the formulations actually use the phrase "implementation-defined" and not "implementation-dependent", I believe the above text should replace "implementation-dependent" with "implementation-defined".

Absolutely, apologies for fumble-finger.

ht
- --
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: ht@...
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFK6ae8kjnJixAXWBoRAtqvAJ9AGXSmIPdG169iVKXJ/M3/BesTcgCfVV2C
M0jSVbLSEH7hjlAlgiyHOYg=
=0peo
-----END PGP SIGNATURE-----

["Martin J. Dürst"]

Hello Henry, others,

Some concerns based on my experience:

1) There may be a good use case for the very detailed rules and texts
below, but I'm quite concerned that sooner or later, all W3C Specs or
TRs will come with even more boilerplate that will cause even more
boring work for WGs and team and will be read by even less people, and
not applicable or unnecessary in many cases. So: Don't make this stuff
(in whatever form or content) mandatory!

2) On the W3C side, you use "edition", which I understand e.g. as in XML
1.0, 5th edition. As far as I understand, "edditions" in this W3C sense
are mainly restricted to errata, and are only produced for
high-maintainance specs. Examples given e.g. for the IETF (RFC xxxx
obsoleeted by RFC yyyy) seem to have a far wider granularity; I don't
know exactly about ISO.

3) In many cases I know, referencing "the earliest appropriate for use
with this specification" seems undesirable. As an example, one could
check a spec carefully and come to the conclusion that where it
references Unicode, Unicode 2.0 is "the earliest appropriate...". Or one
could look at language tags, and come to the conclusion that RFC 1766 is
"the earliest appropriate...". Even if that might technically be true,
it may still send very much the wrong message. That's why in I18N, and
in particular for the above two examples, we have generally recommended
"newest stable (or its successor)", and that has worked well so far. It
may be that this approach works particularly well for specs that are in
their core a list of values. But in some cases, it was also done simply
for making people aware that some things not necessarily directly
related to the citing spec have changed (e.g. it might really be a good
idea now to support surrogate pairs in UTF-16, and 4-byte characters in
UTF-8,...), even if there was no direct connection between the citing
technology and the feature in question.
For language codes, the fact that the spec is a BCP and BCPs have stable
numbers even if the underlying RFC number changes has led to the
recommendation to simply say "BCP 47", with less of a need to say "or
its successor".

Regards,   Martin.

On 2009/10/28 23:57, Henry S. Thompson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the context of an extended discussion at the recent TAG f2f
> regarding references to potential time-varying specification URIs [1]
> I took an action [2] to suggest wording for a Best Practice in this
> area, based on wording developed by C. M. Sperberg-McQueen, who also
> reviewed and contributed to the following.
>
> Here's what I think this might look like:
>
>    When citing a W3C specification in the normative references section
>    of another specification, care should be taken to be clear about the
>    status of editions of the referenced specification other than the
>    then-current one.  In order to on the one hand acknowledge that
>    implementations sometimes lag behind specifications, and on the
>    other that implementations of new editions of referenced
>    specifications should be encouraged, wording along the following
>    lines should be used:
>
>      Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
>      Peter Schickele, Editors.  World Wide Consortium, 29 February
>      2009.  The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/)
>      is the earliest appropriate for use with this specification.
>      Conformant implementations may follow the edition cited and/or any
>      later edition(s).  The latest edition of LHSF 1.0 is available at
>      http://www.w3.org/TR/lhsf/.  It is implementation-defined which
>      editions of LHSF 1.0 are supported.
>
>    The appropriateness of this approach is based on the W3C rules
>    regarding what constitutes an acceptable new edition of an existing
>    W3C Recommendation.  For references to publications from other
>    standards bodies with similar expectations regarding backwards
>    compatibility, for example IETF or ISO, a similar approach to
>    citation is also called for, along the following lines:
>
>      The Extension of MIME Content-Types to a New Medium, N. Borenstein
>      and M. Linimon.  Internet Engineering Task Force RFC 1437, 1 April
>      1993.  RFC 1437 was current at the date of publication of this
>      specification, but may be updated or obsoleted by later RFCs.
>      Conformant implementations may follow the RFC cited and/or any
>      later RFCs which update or obsolete it.  It is
>      implementation-defined which RFCs are supported.
>
>      Intelligent transport systems -- Physical characterisation of
>      vehicles and equipment -- International airline seat pitch
>      measurements. Part 1: Measurement architecture.  International
>      Standard ISO 314159-1:2009, 29 February 2009.  The referenced
>      specification may from time to time be amended, replaced by a new
>      edition, or expanded by the addition of new parts.  See
>      http://www.iso.org/iso/home.htm for up-to-date information.
>      Conformant implementations may follow the edition cited and/or any
>      amendments etc.  It is implementation-defined which amendments
>      etc. are supported.
>
>    In cases where many references require similar treatment, a blanket
>    statement at the top of the references section may be more
>    appropriate:
>
>      Dated references below are to the earliest known or appropriate
>      edition of the referenced work.  The referenced works may be
>      subject to revision, and conformant implementations may follow,
>      and are encouraged to investigate the appropriateness of
>      following, some or all more recent editions or replacements of the
>      works cited.  It is in each case implementation-defined which
>      editions are supported.
>
>     and then simply
>
>      Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and
>      Peter Schickele, Editors.  World Wide Consortium, 29 February 2009
>      (http://www.w3.org/TR/2009/REC-lhsf-20090229/).  The latest
>      edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/.
>
>      The Extension of MIME Content-Types to a New Medium, N. Borenstein
>      and M. Linimon.  Internet Engineering Task Force RFC 1437, 1 April
>      1993.
>
>      Intelligent transport systems -- Physical characterisation of
>      vehicles and equipment -- International airline seat pitch
>      measurements. Part 1: Measurement architecture.  International
>      Standard ISO 314159-1:2009, 29 February 2009.  See
>      http://www.iso.org/iso/home.htm for up-to-date information.
>
>    All of the above formulations assume a definition of
>    'implementation-dependent' along the following lines:
>
>      If a choice is described as 'implementation-dependent', then
>      conformant implementations must document which choice they make.
>
> Comments welcome.
>
> ht
>
> [1] http://www.w3.org/2001/tag/2009/09/23-minutes#item03
> [2] http://www.w3.org/2001/tag/group/track/actions/303
> - --
>         Henry S. Thompson, School of Informatics, University of Edinburgh
>                           Half-time member of W3C Team
>        10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
>                  Fax: [phone], e-mail: ht@...
>                         URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is forged spam]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFK6FvskjnJixAXWBoRAkMoAJwLt6r3r+Vv0Bafj7VXG3lTwTUZCQCbBUQt
> vLwTcIIeuu0opUPciRUtZ/g=
> =TIg8
> -----END PGP SIGNATURE-----
>
>

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...