[sc34wg3] a new name for the Reference Model

[Michel Biezunski]

* Lars Marius Garshol

> --- TMCL
>
> We have actually made decisions, and they are written up in N0226 and
> N0278. We can change our minds, but what's done so far is contained in
> those two documents.
>
> The people on tmcl-wg are about to start work on a description of what
> TMCL is going to be and also a requirements document. If you care
> about TMCL I think you should join that mailing list to participate in
> that work. This discussion is about the TMCL requirements, so I do
> think you should make your views known as part of the process.

I'll do, but again now what matters first to me is how the
pieces fit together. My point about TMCL is in which sense
does it define an application? Since the SAM is "an" application,
or "the" standard application, then I am raising the issue
of the role TMCL will play in the family of TM-related standards.
It's not purely an internal-TMCL issue.

> One major decision taken in Orlando was that TMCL would be specified
> in terms of the SAM. If you want to change that you really need to
> state so loud and clear. And please bear in mind that it will have to
> be built on top of either the RM or the SAM. There are no other
> choices.

It's not either or. It can be both. What I hope is that eventually
there will be a realization that there is no contradiction. I
recognize that you are uncomfortable with this view now, and it's
possible that in order to fix this problem we should discuss
a new rewriting of the RM. I also know there are concerns with
the way the SAM is currently formulated, and by opening this
discussion in an open and frank manner, we should be able
to end up having a stronger, clearer standard that would benefit
from the considerable work that has been done by you and others
with the same goal in mind, i.e., to improve the usability
of topic maps.

> BTW, I'm surprised that you focus on TMCL the way you do. Isn't TMQL
> equally important, and doesn't it have much the same issues?

My impression is that TMQL is how to *use* topic map applications,
it doesn't say what they actually *are*. TMCL on the contrary seem to
me to define the boundary of an application (validity, etc.).

It's possible that your question might lead to realize that
the boundary between TMCL and TMQL may not be as clear as we
think it is. This is another thing that needs to be explored
and clarified.

> -- RM
>
> I don't really understand why a 1%/99% (RM/app) division of
> constraints makes sense. The application will have to specify the bulk
> of the conformance requirements anyway, so why not everything? It
> doesn't really make sense to require people to read two specs, does
> it?

Remember the standard is not only aimed at implementers, it's also
for information users. The conformance clauses therefore are different,
depending what the focus is. The RM insists on the subject uniqueness
and it looks to me this is central to all topic maps conforming
applications (whatever application means). This seems to me as
a good candidate for a building block for the different necessary
conformance clauses. What do you think?

> --- SAM
>
> I'm glad to hear you say that you think the XTM model is all you are
> ever likely to need. I feel the same way. I do find your mention of
> user requirements not met by the SAM/XTM model disturbing, so I would
> *very* much like to hear what they are. We are supposed to finish it
> soon, so it would be good to hear them before it's too late.

Let's try this, waiting for others to supplement this. What if one
considers the SAM as the user of the RM? If the requirements for
interchangeability, interoperability, etc., that the SAM is supposed
to fulfill are more easily handled by the RM which will make
explicit what's happening under the cover (what gets reified, what are the
assertion types, what gets merged, etc.), then it's enough to justify its
existence.

Again, this doesn't necessarily impact the technologies built over
the SAM. It impacts -- only -- the SAM itself, i.e. the standard
application. It means that existing products should not be directly impacted
by the existence of the RM, unless it reveals that for example 2
different applications consider the "variant" (for example) as meaning
something completely different. Then the fact that the RM has an
impact on applications is positive because it obliges to decide
what we want in the model, and by doing that we will avoid future
interoperability problems. I do not think that this means a complete
rewrite of existing software. But we can't avoid putting on the table
discrepancies if any, and we need to decide for each of them which one
we bless as the standard way (SAM-conformant) to do things. We have
this responsibility for making sure that topic map adopters will get
what they expect from our standard.

> As to why the SAM-RM mapping is difficult, please ask SRN to repeat
> his statements about it. He's struggling with those right now, and
> sent me a pretty good explanation of what he thinks is difficult.

I am confident that Steve N. will share his thoughts as soon as
he will be ready to do so.

> As to what it's supposed to be: if you don't feel you know I would
> very much like to hear what it is you are uncertain of. I've explained
> my view of it many times, so I doubt there's any point in repeating
> that one more time without getting some input from you about what it
> is that is unclear.

OK. As I said, my main problem for now is to make
the pieces work together. When we'll all feel more
comfortable about how this works --and I hope it's going
to be very soon-- I am hoping that all contributions will
be resented as positive rather than disturbing. FYI,
I am saying the same to the authors of the RM who are
pressuring me to do the same.

> --- ISO 13250:2000 and XTM
>
> This is the past, and I'm not sure there's any point in discussing it
> much. The facts are that
>
>  - neither specification provided what was necessary for interoperable
>    implementations and documents, and

Documents: it is a question of conformance to a DTD or architectural
form.
Applications: there was not much about it. (Kind of on purpose, but
obviously insufficient now that real applications exist).


>  - XTM 1.0 made changes to ISO 13250 that were not backwards
>    compatible.
>
> Any attempt to tell me that this is so is just going to make me very
> angry, so please don't bother to try. It's better to just leave this
> whole issue alone.

OK. No comment.


> Of course, fixing this is what the SAM is all about, and I hope we can
> soon finish that and move on to new work, such as TMCL and TMQL.

Yes, me too. Just add the RM to the list of stuff
on the agenda.

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