[sc34wg3] Modularization

[Lars Marius Garshol]

Michel, I've read this posting several times now, but I can't make out
what you are saying. Could you start from N0323 and describe what it
is you would like to see done differently?

I comment on specific parts below, but, really, it is not just the
parts that are incomprehensible to me, it is first and foremost the
whole. I suggest that you use the comments below as guidance to what I
didn't understand, in order to better succeed in your next attempt.

(Just saying this because I think that if you start replying to my
comments individually we'll just lose ourselves in the details without
going anywhere.)

* Michel Biezunski
|
| Yes, the existing syntaxes should still be normative.

What does it mean for a syntax to be normative?
 
| I propose a modularization strategy where we clearly separate 1)
| from 2).

Isn't that what the current SAM/RM separation does? I can't work out
how you want your 1) and 2) to be different from the RM and the SAM.

| Any topic map candidate application should be able to be represented
| as 1), but 2) could be replaced by any model that exists or will
| exist and can be mapped to 1). In other words, 2) would be a plug-in
| to 1) that could be unplugged and replaced by another plug-in.

What is a "topic map candidate application", who would create one, and
why? Is it the same as a "model"?
 
| Currently, the SAM as written inherits from the confusion resulting
| in a fuzzy separation between these 2 levels.  Which translates
| partially in the fact that concepts are represented directly by
| syntactical constructs. 

The SAM does not express things in terms of syntactic constructs.
There is nothing inherently syntactical in the notion of base names,
occurrences, or scope.

| We thought when we did it that this was going to make it "easy" to
| grasp, but now I see this as a severe limitation to expansibility.

What is extensibility, and what do we want it for?
 
| The part that corresponds to 2) should define conceptually,
| abstractly, what we mean for example when we speak of an occurrence
| or of a name in this representation.

The SAM already does this.

| It's not enough to give a list of element types. 

The SAM does not do this.

| Because it's possible that other applications will use the same
| notion of names, and other element types. We need a description
| precise enough to know if the model can be assimilated or not.

Of course. That's why I am talking about mapping for example XFML
directly to the SAM.
 
| Last remark: it might be appropriate to change the name "Standard"
| in the expression "Standard Application Model" for a name more
| hospitable to coexistence with others. 

This takes us back to the question of what other models we envisage
and why we would create any.

| Because if another standard organization publishes a standard that
| we can consider Topic Maps-compliant, then there will be another
| standard application model. 

Yeah, but it won't be topic maps. When you write software you'll have
to either implement the SAM, or not implement it. If you implement RDF
you've implemented RDF, not topic maps. If you implement the RM you've
implemented the RM, and not the SAM.

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