[sc34wg3] Topic Maps land and SAM land

[Jan Algermissen]

Lars Marius Garshol wrote:
> 
> * Jan Algermissen
> |
> | The current official draft of the SAM is based on XML infoset.
> 
> No, it's not. It uses the information set formalism, which the XML
> Infoset also does, but there is no connection with the XML Infoset in
> it, nor should there be. 

You are right, I misunderstood this. Thanks.

> It's a data model, and so it does not concern
> itself with syntax in any way.

Right. In my attempt to answer the dialog below I stated mixing things up.

<quote>
> | Jan:
> | So, a SAM defined in RM terms would include a processing model for
> | XTM, saying how all the element's are to be interpreted. 

> Lars:
> Why would it? SAM doesn't have XTM elements in it, so why would an RM
> model of the SAM have them?
</quote>

Another try:

A 'processing model' in terms of the RM is a 'deserialization specification' in
terms of the SAM. So, all the RM is saying is this: For every syntax that a
TM Model defines there must be a deserialization specification that defines
how the syntax is to be interpeted in terms of the semantics of the model.

I suspect that the word 'defines' causes the wrong impression that the syntaxes
are an essential part of the TM Model. What is really meant is that in order
to deserialize the information that is contained in instances of a particular
syntax into an instance of a particluar TM Model a deserialization specification
(aka processing model) is to be defined. 

I assume that this POV is not different from the SAM's, yes?
> 
> | And XML infoset is what the current SAM's underlying processing
> | model is.
> 
> The term "processing model" has been abandoned because it is not very
> useful. Anything you do with a topic map is processing, so "processing
> model" then means "a model for anything you want to do with a topic
> map", which isn't really a very helpful term.

Well, see above.
> 
> The SAM is a data model. In addition, there is an XTM syntax
> specification that contains a specification of how XTM instances are
> to be deserialized into SAM instances. But that's not part of the SAM,
> although it *does* use the XML Infoset.

Agreed. 

> 
> | Without such a thing, it is impossible to make any sense of a
> | processed syntax.
> 
> Well, I'm not sure the RM needs to concern itself with syntax. The XTM
> syntax spec already does that job, 

Do you mean XTM 1.0?

> so all RM needs to tackle is the
> much easier job of dealing with SAM.

Oh, I find the syntax deserialization specifications to be much easier
than defining a TM Model. 

> 
> | Suppose we wanted to define the SAM in RM terms, it would absolutely
> | make sense to me to still base the processing model for XTM on XML
> | infoset.
> 
> I'm not sure what you are saying here. Are you saying that a SAM
> expressed in RM terms would also need to have the XTM syntax
> specification in it? 

No, no! But I agree that the RM might cause this expression and should
seperate the issue of TM Model and desrialization specifications.

> (Why? And what about HyTM and LTM?) Or what?
> (There's too many possible interpretations of this for me to list them
> all.)

Yep, I get your point now (I hope),

Jan


> 
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org