[sc34wg3] Re: Public Interest and ISO WAS: [topicmapmail] <mergeMap> questions

[Steven R. Newcomb]

[Sam Hunting:]
> [steve newcomb]
> > It seems to me that this very technical issue is
> > clearly a public interest issue, and I'm very glad to
> > have an occasion, finally, in this note, to explain why
> > that is so.

> And by "public interest" we mean? (On a postcard,
> please -- so I can understand it.)

OK, here's my postcard.  

  The act of creating an international standard *is*
  the act of defining the public interest with respect
  to everything within the scope of that standard.

(Sorry my postcard is so circular.  It's in the
*resolution of the technical issues* that the public
interest is *really* defined, just as the U.S. Supreme
Court decides, in its deliberations and by voting,
exactly what the laws of the U.S. *really* are.  In a
court of law, as in a design process for an
international standard, it only matters what the
individual case is, how the case comes up, and what
basic principles are held most dear by the people who
are making the decision.  So I return to the issue at
hand; it's the "case" we're talking about.)

Lars Marius indicated that backward compatibility
with existing implementations was a good reason not to
adopt the idea of multiple scopes on associations, in
the standard model.

I take extremely serious exception to his remark on two
levels.

Level 1: The question of whether multiple scopes on
associations should be supported is not an issue of
backward compatibility, because:

  * There is no stated policy in the standard about
    what to do about equivalent assertions, so there's
    no previous provision of the standard to be
    compatible or incompatible with.

  * Existing topic maps don't have multiple scopes, but
    again, *allowing* future topic maps to have
    assertions that have multiple scopes is not the
    same thing as *requiring* it.  Existing topic maps
    would not be invalidated by relaxing the constraint
    that an association must have exactly one scope.
    By definition, backward compatibility is *always*
    maintained when constraints are *relaxed*.
    Backward compatibility problems only occur when new
    constraints are *added*.  Remember: the ISO 13250
    standard is a standard for interchangeable topic
    maps, and what they mean.  Strictly speaking,
    "backward compatibility" for ISO 13250 has to do
    with *existing topic maps*, not with *existing
    implementations.* (Of course, existing
    implementations are important, too, because it's in
    the public interest that the public be able to
    continue to use them.  It's always a balancing act.
    But if they're broken in a way that causes them,
    under certain cirumstances, to handle topic maps
    information unreliably, ambiguously, or
    inaccurately, it hardly seems fair to the public to
    encourage the idea that they don't need to be
    fixed.)

  * Allowing assertions to have multiple scopes (in the
    standard's underlying model -- and there is no such
    model, currently) would not necessarily invalidate
    existing implementations.  It merely provides a way
    for existing implementations that happen to be
    broken (either in that they don't merge equivalent
    assertions, or in that they don't preserve scope
    information when merging equivalent assertions), to
    be fixed in a way that will be standardized and
    will make sense.

Level 2: As you say, Sam, the question of what will
best serve the public interest, and, indeed, what *is*
the public interest, is deeply intertwingled with every
design decision regarding a public standard.  When any
participant has some other perceived basis for making a
technical decision about a public standard, it's
important that we all understand exactly what that
basis is.

Lars Marius's definition of "backward compatibility"
seems to suggest that future versions of a standard
should reflect the *limitations* of existing
implementations.  I strongly resist and denounce this
formulation of the purpose of creating public
standards.  I believe that the purpose of creating a
public standard is to make certain technical decisions
on behalf of the public at large, not on behalf of just
one small segment of the public that happens to have an
interest in making the standard be exactly as crippled
and broken as their existing implementations happen to
be.  When private interests use public processes for
private advantage at unnecessary public expense, we
normally regard such processes as corrupt.

So, I'd like to ask everyone two questions:

(1) If the public interest is *not* the basis on which
    our design decisions should be made, what, exactly,
    *should* be the basis on which design decisions are
    made?

(2) Assuming that there is no valid basis other than
    public benefit for making any particular design
    decision in a public standard, is there any virtue
    whatsoever in keeping the standard exactly as
    limited and/or broken as its existing
    implementations are?

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA