RE: [Bug 4675] add text in section 5.3.3 to require that consumers and producers are required to implement at a minimum the uri scheme

John, basically I think we are in violent agreement once again (as I
bounce back to the two distinct ideas):

 

I continue to see value in defining conformance as we have it now, and
in giving implementers the information they need to make informed
choices about the degree of interop they are guaranteed by the existing
spec's MUSTs vs its MAYs.

 

But the text has to be careful about what it says about the relationship
between conformance and interoperability.

 

Kirk Wilson, Ph.D.
Research Staff Member

CA Labs

603 823-7146

 

________________________________

From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On
Behalf Of John Arwe
Sent: Thursday, December 13, 2007 12:11 PM
To: public-sml@w3.org
Subject: RE: [Bug 4675] add text in section 5.3.3 to require that
consumers and producers are required to implement at a minimum the uri
scheme

 


Forgive me, but: 

>This is a "traditional view" in
>that all other standards (at least the ones I worked on) seem to share
>this understanding.  Thus, we have "interop" sessions to insure that
the
>spec is written in sufficient specificity to insure that conformance
>results in interoperable implementations. 

is to me a gross over-statement.  XML Schema and WS-Addressing are the
two that leap to mind, since SML has made me more familiar with them.
Even very foundational things like RFC 3986 (URI syntax) do not on their
own give you useful interop.  While it might be the original intent to
make conformance = wide interop, if experience has shown me anything it
is the trade-off between those two and spec writers rarely if ever have
the prescience to anticipate all the holes in any natural language.  The
more deeply you read existing standards, the more unspecified corners
you usually find...some intentional, others not.  While it is common to
assume that something we don't know deeply does make conformance = wide
interop (assuming wide adoption, of course, else it's not "useful"
interop), one thorough read is usually enough remedial education.   

I think we have "interop sessions" to ensure that _where conformance is
intended to specify interop_, that this is in fact true.  Not to prove
that the two are equal.  Saying that the two are equal is close to
saying conformance allows zero implementation choices. 

My approach in suggesting the change was simply to get back to the
conformance definition the wg had already agreed to, and to (separately)
acknowledge the effect of areas already in the spec on interop (_none_
of which was new), so we can get to Last Call in the same century as the
schedule articulated in the charter.  Since I had discussed the draft
with Sandy and Valentina before it was submitted (and missed this
subtlety myself then), I know it was not their intent either to change
the wg's already agreed to definition of conformance or to add a new
linkage between conformance and choices that effect interop.  As noted
in several calls, there are implementation choices - points where we
consciously chose to make things optional - which will affect the degree
of interop a given implementation exhibits.  The degree of practical
interop demonstrated by any implementation is contingent in those cases
not only upon the choices made by one implementation, but also by other
implementations' choices and the adoption of each.   

I continue to see value in defining conformance as we have it now, and
in giving implementers the information they need to make informed
choices about the degree of interop they are guaranteed by the existing
spec's MUSTs vs its MAYs. 

Best Regards, John

Street address: 2455 South Road, P328 Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787