[sc34wg3] The schema topic

[Lars Marius Garshol]

 From Norwegian national body commments:

> The schema topic which represents an entire TMCL schema has
> disappeared in this version. This topic is important for being able to
> attach metadata to schemas, such as name, creator, version number,
> source URL, etc etc. It is also important in order to provide an easy
> mechanism for detecting whether or not a given topic map actually
> contains a TMCL schema.
>
> This will admittedly complicate the writing of TMCL schemas in CTM,
> and so there is some cost to including this functionality. However,
> this could be mitigated by defining the standard templates in such a
> way that they create a single schema "behind the scenes", such that
> defining a single schema in a single topic map is handled
> easily. Also, the schema and connecting associations could be made
> optional.

Graham's reply was:

> We had the schema behind the scenes creation but removed it in Oslo.  
> It was ugly/messy as it meant the constructors could only be used  
> for constraints in one schema. If we consider schemas to be in the  
> scope of a map, then reify the map and make annotations about it and  
> runtime merge / virtually merge the schema topic map when needed.

I think we should consider this again. Here's what I think we should do:

  (1) define a topic type for TMCL schemas,

  (2) define an is-defined-by association type used to connect  
constraints
      and types with a schema topic,

  (3) make the use of these optional, and don't attach any validation
      semantics to these PSIs.

This way the CTM templates do not provide explicit support for  
connecting constraints with the schema (unless, that is, we decide to  
add optional arguments to CTM templates). However, people can define  
their own templates, and tools for creating schemas can create these  
associations automatically.

This gives people a way to talk about CTM schemas, which I think is  
useful, and also a way to track what comes from which schema.

An alternative version of this might be to skip points #2 and #3  
above, which would still get us some of the benefit, without any of  
the attendant problems.

Thoughts, anyone?

--Lars M.
http://www.garshol.priv.no/blog/
http://www.garshol.priv.no/tmphoto/