[sc34wg3] A new idea for the Topic Maps standard

[Nikita Ogievetsky]

Lars,

>
> * Nikita Ogievetsky
> |
> | If I do remember well, XTM was started as XML Interchange syntax for
Topic
> | Maps.
> | So this is(!) a normative interchange syntax.
>
> You have to be more precise. What does *mean* when you say "normative
> interchange syntax"? That you must support XTM to support topic maps,
> or that if you support XTM you must do it as the XTM spec says?

I am saying that
1) There exists an XTM syntax that can be processed with SAM
and which can be represented in RM graph.
2) It is enough to support XTM for topic maps interchange.
3) XTM syntax was designed to be neutral enough and powerful enough to be
able
to express any information. That was the point. If this is not achieved,
than we should revise it.

Then XTM is normative in the sense that if you want to send your information
so that it is understood by the other party, it is the safest to send it in
XTM.
But there can be other syntaxes, and other data (processing) models.
There should be only one RM though.

> | On the other hand, if XTM syntax is not powerful enough we should
> | look into making appropriate changes.
>
> I haven't heard anything about it not being powerful enough. What made
> you think it isn't?

I did not say that "I think it isn't". On the contrary I said that if at
some point somebody discovers that XTM syntax is not capable
of representing some kind of information, than XTM syntax may be revised
resulting in a new XTM syntax: XTM 2.0.
Accordingly SAM should be updated to SAM 2.0.
Both SAM 1.0 and SAM 2.0 should be conformant to RM...
Now the tricky question for Steve Newcomb: what's with RM versioning ?

> | Here is how I see RM and SAM positioned:
> | The translation from somebody's structured information into
> | XTM syntax should be done on the RM level.
> | SAM is a RM conformant processing model for XTM.
> | (application model with processing rules)
> | When people have information expressed in various syntaxes,
> | they should first convert it to XTM syntax based on RM,
> | then process this information based on SAM.
>
> What's the point of going via the RM? And aren't you contradicting
> SRN's proposal for a new conformance section for the RM?

How am I contradicting it? I missed that.

> Also, we agreed in Berlin to stop using the term "processing model",
> as it wasn't clear what it meant. Anything you do with a topic map is
> processing, so calling it processing model is really equivalent to
> calling it "the model for everything to do with topic maps", which is
> not what I think you mean to do.

Thanks for understanding me :-) . I am calling SAM data model now, but I am
not
happy with this one neither (nor with "application" model).

> | Alternatively people can implement their own RM compatible
> | processing models and process Topic Maps the way they want.
> | But why? - given a set of SAM enabled open source and commercial tools.
> | Besides if they do some proprietary staff they will have a hard time
> | interchanging with the rest of the world.
>
> Agreed. I think we should be careful not to encourage people to take
> this route. As Patrick says there may be special cases where people
> want to do it, for example because they don't want to use Unicode, but
> we shouldn't encourage them to do so, precisely for the reasons you
> mention.
>

--Nikita.

Nikita Ogievetsky, nogievet@cogx.com;
Cogitech Inc.        http://www.cogx.com
Topic Maps Tutorials and Consulting.
phone:  1 (917) 406 - 8734