[sc34wg3] N0391-0394: New SAM/XTM documents

[Michel Biezunski]

Lars.

> * Michel Biezunski
> | 
> | However, I don't think that there is any reason
> | to hurry. 
> 
> I don't agree.

You don't say why. It's not enough to say you
disagree. Why is it desirable to not bring all the
various projects being worked out within the
Topic maps community together to the level
where everybody understands what the others
are doing?

Otherwise, it's like having a country run by warlords.
Everybody in his own right is convinced that
he owns the truth. 

There are common, shared values, that are above 
private interests and need to be the ones on 
which the standard is based. That's my message.
If you get that, you can skip the rest.

> 
> | I understand that as far as you are concerned,
> | you consider the SAM pretty much as cooked. 
> 
> Correct. And it's not me alone who thinks that.

I think it is too. But I think it may not exactly
fit the best possible role and it might lead to
limit the acceptability of topic maps, rather than
favor it. That's my biggest problem.

> | But now starts the process of studying every piece of
> | it to make sure that it fits the common needs that
> | we have the mission to provide as a standard. 
> 
> You've had two years to do that.

Not for the very last version. Not with all the
open issues that have remained. Not will the issues
that still remain and are being raised. Not with
the new Topic Maps model just released a few
days ago.

As one of the editors of the standard, it is
my role to make sure that not only things are
considered ready by authors of individual
documents, but that it fits the big picture
of where topic maps fit. 

You have authored a document. Fine. You now
have to accept to have it reviewed until it's
completely satisfying. It has to fit with the
other pieces, and we need to see if the
connection with the TMM works fine or not.
There are still open issues to be solved.

> | I don't believe that at the point where we are
> | now, having tight deadlines for publishing is
> | of any help. On the contrary, if we want topic
> | maps to succeed on the long term, we'd better
> | work our way out to make the various pieces make
> | sense together, instead of against each other.
> 
> We did work out a way to do that in Berlin, and we published it as a
> our roadmap. That has been followed ever since, and nobody, except
> you, has gone out to say that they are not satisfied with it. You did
> say you wanted some changes, but were unable to explain *what* you
> wanted. 

No, I didn't say that.

The roadmap is fine, globally speaking. I am
advocating for implementing it, i.e., making sure
that all pieces that we already have work together
as they should and we are not going to have some
big problems in the future for having spent not
enough time on those.

 
> | I can understand your desire as an implementer to get 
> | things clarified, [...]
> 
> What you don't appear to understand is that there are other pieces of
> work waiting for this one, and they are becoming increasingly urgent.

Yes, and there are pieces that are waiting to be
made compatible with each other.

> We don't have much of a standard so long as people are forced to build
> their solutions using proprietary technology. Nor do we look like we
> are going anywhere when despite having worked on topic maps for 7
> years (since the start in ISO in 1996) all we have finished is two
> syntaxes. 

Not true at all. SGML and XML have no technologies built-in. The power
of these standards is that they let their users design their own
architectures and tools and you can do lot of stuff with no relationship
with each other, and that's exactly what I want for topic maps.

We are going somewhere. SAM represents a progress in comparison to
where XTM was at the end of 2000, and we also have a model (TMM) which
is a progress compared to where RM was even a few months ago.

Also you seem to ignore the fact that when the ISO process was
initiated in 1996, the Topic Maps model was pretty much designed
so it's even older than what you say.

Seeing the progress being made on this side of the Atlantic
on the credibility of topic maps and their acceptability, I
am really baffled to hear that "we are not going anywhere".

However the lesson I learned over these years is that impatience
is the worst enemy. It's because topic maps are
*conceptually* strong that they are gaining momentum. This
takes an awful lot of time, and the small size of most of the 
companies involved in the topic maps standard groups makes it
difficult to get a message across the whole world, just because
we do what we can with what we have. I think considering these
factors we have not done too bad for the time being,
and there are good and new opportunities still on the way.

When you say we "just have two syntaxes" to mean we don't
have anything valuable is a negation of the reality. Like it
or not, many people consider an interchange syntax as a
way to interchange information in a standard way. Having XTM
being an implemented import/export format for many TM-based 
applications is actually working. The fact that it's not working
perfectly, that there are some details that need to be clarified,
that this is the purpose of the SAM, yes, all that is true.

But let's put things back in perspective. The SAM is a bug-fixing
document for XTM. My point is that we need to be sure that the
bugs are actually fixed, and that there are no other new bugs
introduced. That's all I am saying.

What works or not with a given piece of technology is out-of
scope as far as the standard is concerned. This standard is much
more ambitious than describing the state of the art between
existing software. We also need to include provisions for
defining new, unheard-of, puzzling, piece of technology to
accomplish the perspective that we are setting forth. That's
what we did from the beginning. Topic maps is about knowledge,
it's not about software. The fact that there is software out
there that claims that it's able to process topic-maps related
information is good, but not enough.

I don't think the standard should be limited to what
current products can do. 

We need to evaluate whether this is all what the SAM is
about or if there is something else to it. If there is
something else, it has to be connected to the bigger
picture of topic maps. By denying the requirement to 
do so, you are driving the standard in a narrow place
where it will lose much of its attraction. That's what
I want to avoid. I don't think any company involved
in the standard committee has such an interest, including
yours, Lars.
 
What you are doing with the SAM is an extremely valuable 
contribution to the standard, and everybody in the committee 
I am sure appreciates the value of what you are bringing. 
But this is not equivalent to the standard. It is only a piece. 
Your willingness to put that in the center is *the* problem 
that needs to be addressed. If we go in your direction, we 
lose the fact that topic maps have been designed since the 
beginning as a neutral platform to describe the meaning
of the connections between information objects. 

There will be standards out there that will be simpler, 
more powerful, and more neutral than what you are proposing, 
and will be therefore more attractive. What I am proposing is that 
we as a group start designing these standards. And if we
do our job correctly, they might still be called topic maps.


Michel

===================================
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Email:mb@coolheads.com
Web  :http://www.coolheads.com
Voice: (718) 921-0901
==================================