---

CTM - Meeting notes Oslo 23.03.2007

Table of Contents

• General requirements / tasks
• Template invocation
• Template invocation using infix and prefix notation
• Strings
• Generation of new topics
• Introduce NULL datatype
• Discussion of the CTM issues
• Are templates topics?
• Reification of topic maps
• Do we need a different syntax for subject identifiers / subject locators
• Align supported datatypes with TMQL
• Does CTM contain syntax elements that do not play well with the syntax of TMQL?
• Make explicit that every name is a subtype of a TMDM topic name and that every occurrence is a subtype of a TMDM occurrence
• Allow system-dependent commands for the include and mergemap directives

General requirements / tasks

Template invocation

The optional usage of the brackets for one argument should be removed: The editors were requested to make a decision if the brackets must be used regardless of the number of arguments or if they must be omitted for one argument.

Template invocation using infix and prefix notation

The editors were requested to provide a solution to use the template identifier in prefix and infix notation.

Infix notation

arg0 template-identifier arg1

Prefix notation

template-identifier(arg0, arg1)

Strings

Single quoted strings are limited to one line. They should be able to span more than one line (c.f. triple quoted strings).

Generation of new topics

CTM should provide a mechanism to generate new topics which are not identified by an item identifier, subject identifier or subject locator which is provided by the user but where a topic with a unique item identifier is created by the CTM processor. CTM must provide a notation which makes it possible to refer to the created topic without knowing the concrete item identifier.

A proposal was made that the notation uses a wildcard (*) and an optional identifier which is used to refer to the created topic (i.e. *foo).

Introduce NULL datatype

The TMQL-discussion has shown, that the query language requires a NULL datatype. Since all built-in datatypes of TMQL are defined by CTM, the editors were requested to introduce a NULL datatype that may be reused by TMQL.

Discussion of the CTM issues

This section provides the results of the discussion of CTM issues. See also document N0821 for a detailed description of these issues.

Are templates topics?

During the discussion of this issue, the following proposals were made for the template syntax:

1. This proposal uses the same syntax as topics. The occurrence ctm:body is used for the template content.

   born isa ctm:tpl
   ctm:body: """
           [...]
   """        
          

   Votes: +3

2. Current (draft dtd. 2007-02-22) template syntax

   ctm:tpl born
       [...]
   end      
          

   Votes: 0

3. Alternative syntax that uses a period to mark the end of the template

   ctm:tpl born
       [...]
   .        
          

   Votes: 0

4. Syntax that uses the keywords def and end for templates

   def born
       [...]
   end 
          

   Votes: +9

Result: The alternative #4 is used as template syntax. The committee made no decision if a topic is created for a template. This decision is left to the editors.

Reification of topic maps

Proposals for a notation to reify a topic map:

1. Using a special topic identifier ctm:self that creates a unique topic identifier that is used to reify the topic map

   ctm:self
   - descr: "This is my topic map about...."
         

2. Reification of the topic map using ~ topic-identifier where the identifier must be named again to attach further information to it.

   ~ my-topicmap
       
   my-topicmap 
   - descr: "This is my topic map about...."
         

3. Allow the usage of the reifier notation (~) with a topic identifier without a preceeding Topic Maps construct (like association, occurrence, name).

   ~ my-topicmap 
   - descr: "This is my topic map about...."
         

Result: Alternative #3 was favorized by the majority.

Do we need a different syntax for subject identifiers / subject locators

Decision: The keywords sid and slo are obsolent. Remove them and use the common notation for subject identifiers and subject locators.

Align supported datatypes with TMQL

Due to a voting process the following datatypes were accepted to be used as built-in datatypes. "Built-in datatype" means, that it may be written without quotes and without an explicit datatype indicator. The alternative syntax "value"^^(QName|IRI) can be used for datatypes which are not built-in.

These datatypes are also normative for TMQL.

Note: The following list refers to the names of the XML Schema Datatypes

• anyURI (IRI)
• string
• date
• dateTime
• integer
• decimal

During the discussion, the following TMQL requirements were extracted:

• De-/serialization
• Comparators
• Functions/operators ontop of the datatypes

Does CTM contain syntax elements that do not play well with the syntax of TMQL?

This issue was left unsolved. The CTM editors were requested to provide a more stable CTM draft and to submit it to the TMQL editors. The TMQL editors are responsible to react on the CTM draft and to identify syntax incompatibilities (if necessary).

Make explicit that every name is a subtype of a TMDM topic name and that every occurrence is a subtype of a TMDM occurrence

The committee decided that the CTM standard is not responsible to provide such information. The CTM document should be silent about it (like XTM) and the "TMDM -> TMRM mapping" should make this information explicit.

Allow system-dependent commands for the include and mergemap directives

The editors were requested to think about a mechanism to use system-dependent commands instead of an IRI for the mergemap and include directives.

Allowing user-defined directives that may be ignored by CTM parsers which do not understand them might be a worthful alternative.

No decision taken, left to the editors.