[sc34wg3] Modularization

[Lars Marius Garshol]

Michel,

thanks a lot for this latest response. I'm much closer to
understanding what you say now. I'll skip the details, because I
believe I have finally understood the main point. If I've overlooked
something important, please tell me.

As far as I can make out, this is what you would like to see changed:

 - the definition of the topic map concepts moved out into a section
   separate from that of the data model (information items with
   properties[1]), and

 - to make it possible for technologies that are not topic maps to
   still conform to the topic map standard.

In addition you seem to express the following wishes, which the
current drafts already comply with:

 - a continuation of the current division of the SAM and the XTM/HyTM
   syntax specs into different documents,

 - a continuation of the use of the infoset formalism for the data
   model part of the SAM, and

 - a continuation of the practice of phrasing the conformance sections
   of each ISO 13250 part in such a way that implementations can
   choose to conform to any subset of the parts.

Did I get that right? (I still can't make out what your proposed list
of parts for 13250 is. If you want it changed from N323, please put
forward a proposal.) I'll skip the parts that are already as you want
them and focus on the rest.

I think your concern is that the SAM requires topic map
implementations to have a particular internal structure that conforms
to the SAM. If we follow my proposal an implementation can

  a) conform to XTM, without conforming to any other part of 13250[1],

  b) conform to HyTM, without conforming to any other part of 13250,

  c) conform to the SAM, without conforming to any other part of
     13250, 

  d) conform to the RM, without conforming to any other part of 13250,

  e) conform to TMQL without conforming to more than one of SAM, XTM,
     and HyTM, and possibly not even one of them, and

  f) conform to TMCL without conforming to more than one of SAM, XTM,
     and HyTM, and possibly not even one of them.

Doesn't that mean that we still have flexibility with regard to how
implementations approach topic maps? To take a very real example, this
will allow Mondeca to say: we support XTM, HyTM, TMQL, and TMCL, but
not SAM or RM. In other words: implementations can have whatever
internal structure they please, and they can conform to the SAM if
they *wish* to do so.

Now, to turn to your request about separating the concepts out of the
data model definition. We can of course do that, but the question is
what the point is. You can't actually conform to concepts in a way
that can actually be tested, so what's the point? Separating them out
doesn't give anyone any more flexibility.

I understand that you also want it to be possible for, say, HTML to be
regarded as a topic map application. I think we agree on the end
result: we both want it to be possible to generate topic maps from
HTML sources. The question is why the standard should involve itself
in this. If we made the standard so fuzzy and vague that even Netscape
HTML can conform to it, what have we gained? As far as I can tell
we've created something that's so vague that it isn't anything at all.

If, on the other hand, you want to make it possible to create a
mapping from HTML to topic maps, we already have the capability to do
that. And, what is more, we have the capability for different end-user
projects to create whichever mapping suits them best. So what more do
we need?

As for all this talk about sitting down at the table and reassembling
all the pieces: sure, we could do that. And while we are playing with
our puzzle the published subjects work must wait for us, as must the
work on TMCL, and the work on TMQL, and the work on the SAM, and the
work on the RM, and the work on the XTM syntax, and the work on the
canonicalization syntax, and the work on the conformance test suite.

So long as I don't see any point to what you want to achieve by that
reassembly I have to say I don't care for the idea.

[1] See N323 for the proposed parts list.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >