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

[Kal Ahmed]

At 12:05 18/10/2001 -0700, Sam Hunting wrote:
>[kal ahmed]
> > Is it "fixing broken aspects of the  spec(s) or paradigms" ? Because
> > I'm not convinced (yet) that it is.
>
>If you were convinced that the spec or the paradigm were broken, and
>that to be fixed, changes that were backwards incompatible for
>applications had to be made in the spec, would you support the changes?
>That's the question before us.

Yes I would support it. However, your definition of what constitutes broken 
and mine are possibly different.

>I suspect you would answer (as I do) that "it depends" on a lot of
>factors -- some of which I list above. I think that public interest is
>one such factor. I also think that "backwards compatibilty" is not a
>fetish to be worshipped, but a principle to be applied on a case by
>case basis. The W3C folks revise their specs -- why shouldn't the topic
>mappers?

Perhaps you can tell me which W3C specification underwent a revision which 
altered its core model within 12 months of its publication ? Perhaps you 
could also comment on the nature of the process that led to that change ? 
Was it before or after a large, widespread user community developed ? I'm 
not a W3C historian (nor a legal expert...the more I write on this thread, 
the less I know apparently ;-) so I would appreciate being pointed to an 
example from which to learn.

>[kal ahmed]
> > And did I suggest that we couldn't / shouldn't ? All I'm saying is
> > that attempting to finesse the discussion by claiming that a
> > particular point of  view is ITPI, is not a way forwards.
>
>Perhaps not for you. Perhaps for others.

I don't know how many sentences that I have to start with "IMHO". IMHO 
perhaps it should be all of them, just to be clear that this is MO (bit it 
H or otherwise).


>[sam hunting]
> > >I like what Patrick says on backward compatibility very much. He
> > >writes:
> > >
> > >Existing implementations should inform the process of
> > >formulating a public standard, not define its limits. Prior font
> > >standards (and implementations) at least defined failing strategies
> > >for the eventual /10646 standard.
> > >
> > >Can you agree with this?
>
>[kal ahmed]
> > WE HAVE A STANDARD !
> >
> > Sorry to shout,
>
>As the master of cliche on this list, I cannot resist the followin
>citation--"If you can't argue the facts, argue the law. If you can't
>argue the law, pound the table..." In any case, look at what Patrick
>wrote. He uses the words standard several times. And do you disagree
>with his approach?
>
>As a point of terminology, we do have a standard (ISO 13250) and we
>also have a *specification* (XTM 1.0).
>
> > but I feel like we are making like we are still in
> > development mode. Yeah, sure, if we want to start work on XTM 2.0
> > then working with 1.0  as a fail-over could be a valid starting
> > point, but we are not. We have XTM 1.0 - some of us like it, few of
> > us like all of it. So what. Lets get on with defining models that
> > work with XTM 1.0
>
>and also 13250

An oversight to miss it out of that sentence. I certainly do want it 
recognised that ISO 13250 exists, it was published less than 2 years ago. 
If we change it now don't we expect the user community will get nervous ?

> > that enable us to develop TMCL 1.0 and TMQL 1.0. Lets not revisit
> > basic model issues.
>
>I'm unclear on the distinction that you draw between defining models
>that work with XTM 1.0 and basic model issues that we should not
>revisit?

Lets build TMCL 1.0 and TMQL 1.0 on the models of ISO 13250 and XTM 1.0, 
not on the "fixed" model that has no representation in either interchange 
syntax and no extant support in the vendor community.

> >  Implementors have dutifully coded ... Moving the goal posts now can,
> > in my opinion, only hurt topic maps.
>
>(I note, in passing, that "only hurt topic maps" is a public interest
>argument....) Seriously, though, this seems to argue that *any* change
>that causes implementors to have to recode *anything* is, by
>definition, undesireable. Please assure me that this is a grotesque
>caricature of your position!

This is a grotesque caricature of my position.

>What I am seeking is not not not not a resolution of the scopes issue
>-- that is for another thread. What I am hoping to discover is if there
>are any shared principles by which we can "move forward" -- this seems
>to me to be bigger game than the scopes issue. Of course, I could be
>naive to even seek this, and the standards world is a Hobbes-ian
>jungle.

IMHO "moving forward" is two things:
1) Developing ancillary standards - TMCL, TMQL, a topic map API
2) Fostering and supporting a user community around topicmaps and the two 
existning interchange syntaxes

IMHO "moving forward" is not:
1) Altering a basic assumption made by both users and vendors (that 
association roles only have one scope) without first hearing a clamouring 
from one or preferably both of those communities.

Cheers,

Kal