[sc34wg3] CTM Comments

Lars Heuer heuer at semagia.com
Fri Mar 30 07:20:32 EDT 2007

Hi Robert,

> In the following a write-up of (editorial) comments I had for the
> Oslo version. Some things might be obsolete, sorry for that. If things

Thanks for your comments.

> - reification
>   I still wonder why this is not
>   mymap ~ ctm:self

It is now settled to

   ~ mymap
   descr: "This is my first map"

The notation you propose wouldn't work, since ctm:self will be
expanded to a subject identifier and the code above will say:

   The topic with the subject identifier "ctm:self" *reifies* the
   topic with the identifier "mymap".

Which is not possible (the topic ctm:self and the topic mymap must be
merged into one topic).

> - 3.3.4
>   Which 'topic' is referred to? Maybe use the parent node/context?

The topic that is specified by either an item identifier, subject
locator or subject identifier. It has nothing to do with the 'parent
context'. If someone writes

     member-of(member: john, band: the-beatles)

the "member-of", "member", "john", "band" and "the-beatles" are topic

The clause 3.3.4 refers to the 'general' topic references, while
section "3.5 Topics" introduces the "topic declaration" mechanism, i.e

     - "John Lennon"
     homepage: http://www......

> - 3.3.6

>   For reifier which should find something 'arrow-ish'

>    ~~>
>    ~> ... whatever

>   which can be reversed

Hmm.... The general agreement in Oslo was, that the reification
mechanism should not add too much syntax. BTW: CTM does not support
'forward' reification, but even with "~" it should be possible to
support reification in both directions.

> - 3.6

>   Maybe make use of parent context?

>   'type' ambiguous because there is the assoc type and the role type.


> - 3.9
>   I again propose ! instead of -.

Reasons? IMO the hyphen is very nice because it is aligned to the
general notation of enumeration in texts. An exclamation mark catches
more attention that it should.

>   Not sure about the grammar. Maybe this is better?
>    name -> '!' [ type ':' ] string .....

We support the following notations:

   - type: "string"
   - type "string"
   -: "string"
   - "string"

The reason for this bunch of alternatives: Striktly speaking the colon
is not necessary for the grammar, but the colon aligns the notation to
the occurrence notation and the committee agrees that the colon makes
it more readable. For untyped names (resp. names where the default
name type is used) the construct "-:" may be too much syntax and the
     - "string"
variant looks better.
But I'll look into this issue again and revise the grammar if

> - 3.9

>   I again propose that ""s are dropped where not necessary. I will
>   re-raise this as issue.

Personally I agree 100% with you, but CTM has other requirements and
the committee agrees that we need a consistent syntax for strings. The
notation won't change. "Der Drops is gelutscht"

> - 3.12
> - 3.13

>   Maybe show how templates can be use standalone:

It will be in the next version. Currently CTM does not support
standalone usage of templates. But the next version will support it.

> - 3.18 and 3.17

>   I still wonder whether it should be possible to merge the two into one
> mechanism.

IMO it is not possible since the include-process is very much
different from the mergemap-process. The current CTM draft is not very
circumstantial about the differences but the next CTM draft will
explain it in more detail. You could use the same *directive name*
with different arguments, but having two directives is more explicit.

> - 3.18

>   Why is there a restriction that only "mentioned" syntaxes can be used?

Nope. See the note:


      A CTM processor should be capable to support the above mentioned
      syntaxes. For any other syntax a CTM processor may flag an

The user may use any other syntax, but a CTM processor may not support
them. To be standard-conform, a CTM processor MUST support at least
the mentioned syntaxes.
>   Is the text block starting with "During deserialization" necessary?

Well, it describes the merging process. Leaving the text block out,
the meaning of the directive would be unspecified... .

> - 3.19
> Quoted strings can contain now linebreaks, yes? In any case, it must
> be always possible to escape " and """.

ACK. ACK. :)

Best regards,

More information about the sc34wg3 mailing list