Re: ACTION-350: Best practice for referring to specifications which may update

On Tue, Jan 17, 2012 at 9:10 PM, Larry Masinter <masinter@adobe.com> wrote:
> What is too complex and ultimately wrong  is to give options to those
> writing specs that make references.
>
> "loose bindings" can't be automatic, because there is no way to control,
> But normative references should not automatically require updating
> the referencing spec; if there are incompatible changes, then the update
> might be made by publishing an applicability statement instead, though.
>
> All references should be
> (a) dated, versioned editions in the link
> (b) by default, all references are "loose bindings", without
>  any explicit disclaimer.
>
> To confirm that a reference is appropriate, W3C working groups could
> be encouraged to publish applicability statements, e.g.:
>
> "Working group finding:
>
> Spec A is still valid with B.v1 replaced with B.v2 and C.v1 replaced with C.v3
> (except note that referenced section 3.6 in C.v1 is now found in section
> 7 of C.v3)."

I'm not intending to disagree with anyone here, but...

The prime question is not the validity of a spec, but conformance of
agents to a spec (or if the spec talks about multiple agent roles,
then to some role in the spec, but let's ignore that for now). We want
to be able to make simple statements like "Z conforms to A" and be
understood. One could define this to mean conforms to A and (by
'tight' normative reference) to B.v1; or one could define this to mean
conforms to A and (by 'loose' normative reference) to B.v1 *or any of
its legitimate successors* such as B.v2.

I think you're right that the latter is risky. B might get forked,
i.e. the legitimacy of successors could become a matter of confusion.
If I think B.v2 is legitimate and B.v3 isn't, and you think the
opposite, we will miscommunicate.

Mathematically the right thing is to treat A as a function from
conformance classes to conformance classes, and speak not of agent
conformance to A but of conformance to A(B.v1), A(B.v2), and so on.
But that's probably too persnickety for anyone to accept... and since
the B specs themselves also have normative references the full
descriptions would probably become unwieldy.

Often of course being specific doesn't matter, because the agent
conforming to A doesn't exercise any feature that belongs to B.v1 and
not B.v2 (or vice versa). That is, it conforms to *both* B.v1 and
B.v2, and therefore to both A(B.v1) and A(B.v2). Often differences in
the B specs won't even be observable to A-conforming agents since only
a limited part of the B spec is accessed by the A spec. This just says
that getting people to treat A as a function is a lost cause, but it
also points to the idea that a normative reference to a whole spec is
wrong, that A should always speak of *what aspects* of B.v1 it
normatively references, to make it easier to make the inference that
conformance to A(B.v2) holds (because B.v2 is unchanged relative to
B.v1 *in those aspects*).  -- Maybe this is similar to what you were
saying in your "working group finding" example. Maybe when you state
as a theorem "spec A with replacements R is valid" that's like my
stating "any agent conforming to spec A will also conform to spec A
with replacements R" ?

This interacts with any theory one might have about compatible
extension points. An agent that depends on an exclusive feature of
B.v2 might still conform to A(B.v1), if B.v1 leaves extension points
unconstrained. If on the other hand B.v1 says that its features form a
complete set, then any extension (B.v2) is incompatible. This
distinction might alternatively be put, not in the wording of the
specs, but into the definition of "conforming". If you think
conforming means just that you agree with what a given spec explicitly
says, but are otherwise unconstrained, that's quite different from
thinking that conforming means that everything you do is documented by
the spec. The latter ensures that you'll never get simultaneous
"conformance" to B.v1 and B.v2 (although IMO it would be a ridiculous
requirement since any useful agent is always doing more than what
specs tell it to - it's doing what *it* wants to do too, i.e. agents
*are* extensions).

I don't know what the answer is, just trying to take the exploration
another step.

Jonathan

Received on Wednesday, 18 January 2012 14:13:29 UTC