CTM - Meeting notes Oslo 23.03.2007
Table of Contents
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:
-
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
-
Current (draft dtd. 2007-02-22) template syntax
ctm:tpl born
[...]
end
Votes: 0
-
Alternative syntax that uses a period to mark the end of the template
ctm:tpl born
[...]
.
Votes: 0
-
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:
-
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...."
-
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...."
-
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.
