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

[Michel Biezunski]

Lars,

> 
> We decided we wanted two models, and documented our plan for how to
> proceed in the roadmap, which was published just after Berlin. Are you
> unhappy with that? If so, how?

I don't know what it means to have 2 models.
I know what topic maps mean. That's different.
And I don't want to go out on the market
explaining: well, there are 2 models because
we couldn't figure out how to agree within
the group. Pick the one you prefer.

No, I won't do that. This is not a viable solution.
I want to understand why topic maps are the way
they are and how many layers (not models) there
are, how they fit together, and what's needed
for what kind of application, either existing
or future. And I want to be able to address
some "exotic" kinds of knowledge, where things
appear to be much more complex than what most
of us think. I also want to be able to provide
simple, straightforward, immediately implementable
solutions. And guess what, I want all of that
to be interchangeable and interoperable. Pretty
ambitious? Yes. Doable? Yes. Ready to fly? Don't
think so.

  
> The changes since it was first published in May 2001 are very small,
> so I can think of no possible reason why you couldn't have raised your
> issues with it before.

You continue not understanding what I'm saying.
It's not necessary to continue at that level.
I am interested by the foundations on which this
is built, I believe they have to be as strong as
possible. You are mentioning some details which
I believe have been properly handled. I don't have
any thing specific to add on those. I trust the
people who are discussing them. To make things perfectly
clearly, I am not doing a rant because there are things
I have not discussed when it was time, I am trying
to address new, current, and future issues.

> Then review it. It's been out for review for two years. I'm still
> waiting for a review from you.

This is why we have meetings.

> 
> | It has to fit with the other pieces, and we need to see if the
> | connection with the TMM works fine or not.  
> 
> We're waiting for SRN on that one, and he has yet to deliver. That
> delay is holding up other work, and please don't try to pretend that
> you don't know that.

Don't blame others please. Everybody is doing his best
in this process. I don't think it's helpful to accuse
others of not doing something. Don't accuse me of trying
to pretend something like that. I don't like it, I don't
think it's productive. I would be really grateful to you
if you could stop using this style of accusation which
has a global result of making the whole work painful,
whereas it could be exciting. Please think about it.

Instead, I think that SRN as you put it, Steve Newcomb
to be more explicit, deserves the credit for having
invented topic maps at the first place, and continuing
to do so now. The model on which the SAM is based is
Steve Newcomb's baby.

(I played some role too, but I can tell you that I could
not have done anything in this area without SRN).

What I find the most amazing now is that Steve is still
providing us with a deep understanding of what topic
maps mean, and I know by experience that you really
should care about his insights, because he is often
right on the long term (despite the fact that he sometimes
has a hard time making himself understood to start with!)
I believe we now have an opportunity to enter a new
stage in the elaboration of the future standard.
And there are also new user requirements coming in which
fit that perspective.


> That just reinforces my point, doesn't it? Instead of 7 years it's 8,
> 9, 10, or whatever.

If we would have been in a hurry, we would have cooked
a quick XML application and it would have been long forgotten
now.

> | 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.
> 
> Well, go ahead and do it, then. How much longer do you want us to
> wait before you can tell us what the problems are or what you will do
> to identify them? 

Until we build a consensus. There is no way to avoid doing
that within an ISO standard process. This is the basis
principle for standardization. 
  
> | 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.
> 
> That's what we are doing, is it not? What I am saying is that what we
> already have needs to be moved forwards while we at the same time
> continue the future-proofing work.

OK, then things are not as bad as they initially looked.

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
==================================