- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Sun, 18 Dec 2011 12:49:13 -0800
- To: Marcos Caceres <w3c@marcosc.com>
- CC: Marcos Caceres <marcosscaceres@gmail.com>, Rigo Wenning <rigo@w3.org>, "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, "Art.Barstow@nokia.com" <Art.Barstow@nokia.com>, Thomas Roessler <tlr@w3.org>, Doug Schepers <schepers@w3.org>, "plh@w3.org" <plh@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
On 12/18/11 2: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.). "Keeping up with the specs" is a business decision NOT something that is tied to compliance with a standard. In fact, in some cases, it may be mandated (by law or commerce) that one does NOT keep up and instead relies on a specific version. Use of undated resources prevents that. In what way do you believe that it is "built into" HTML5 or SVG? Both of those W3C documents use dated references. >>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. That's one way to read it, mine is the other way. > 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: Browsers are just one of MANY types of software in the world that may choose to adopt this standard. Some of those other types may not be on such short cycles. Some of those other types may not be ABLE to rev often (think hardware/firmware, medical devices, etc.). Some of those other types may be operating in mandated environments (think government). >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). A "spec", probably true. An international standard from a reputable SDO - EXACTLY THE OPPOSITE! It is a REQUIREMENT that standards issues by SDO's be dated and frozen at a given point in time in order for them to be implemented, validated and approved for use in mandated environments. But then the "living standard" argument continues to wage in many places and I don't see a need to continue it here. Leonard
Received on Sunday, 18 December 2011 20:50:10 UTC