+1 for Marcos' position. If the W3C performed compliance testing, then it
would perhaps be more appropriate to reference specific versions, at least
in a compliance test specification. However, the W3C has historically not
defined compliance test specifications or perform compliance testing of
either content, servers, or clients.
Instead, external organizations that do have an interest in compliance have
published compliance test specifications that do make reference to specific
versions. I think this approach is more appropriate and more consistent
with W3C practices. This provides a compromise between the W3C's need to
innovate and author and device manufacturer needs to define a level of
interoperability consistent with some compliance test specifications. Many
(most?) authors don't particularly care about strict compliance. Only in
certain industries and content domains is compliance assigned a high
priority.
Let W3C specs use non-specific references where it makes sense, and let
other organizations (or even the W3C if desired) define separate
specifications that map these non-specific references to specific
references in the context of a specific compliance test specification.
Regards,
Glenn
On Sun, Dec 18, 2011 at 12:31 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>
> On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote:
>
> > Undated references (what you are suggesting) has the MAJOR PROBLEM that
> it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that
> claims conformance to a standard – since it's impossible to determine which
> version of each undated reference they used.
>
> That's a FEATURE, not a "problem". Makes it inexcusable not to keep up
> with specs (same design built into HTML5, SVG, etc.).
>
> See also how this de-cupling worked for XML:
> http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html
> http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html
>
> > Additionally, it makes interoperability difficult/impossible since you
> can have multiple valid conforming implementations BUT they don't actually
> interoperate due to changes between revisions (and algo changes would be a
> good example of such an interoperability issue).
> I don't see how that is possible: if your spec does not conform to
> /latest/, then you are non-conforming. If you were conforming yesterday,
> but a new version of the a spec comes out tomorrow, then you update your
> software to conform to the latest version. As an example, almost all
> Browsers are on a 6 week release cycle now: so it's quite inexcusable to
> expect to just conform to some dates draft and then expected to never have
> to update the software (i.e., conformance is an ongoing "living process":
> specs are buggy, tests are buggy, and software is buggy… any of those can
> affect an conformance over time: the are all living things).
>
> Pretending that slapping a date on spec means anything is unhelpful (and
> actually harmful, because all specs contain bugs and hence must be
> continuously maintained).
>
> --
> Marcos Caceres
>
>
>
>
>