[sc34wg3] Supporting variants in TMCL

[Steve Pepper]

* Lars Marius Garshol
|
| * Steve Pepper
| >
| > Are Naito-san and I really the only two users of non-SAE languages
| > that care about variant names? Are they not widely used in Korea
| > and China, for example, as well as Japan? What about topic maps in
| > Cyrillic, Arabic, Devanagari, etc. etc.?
| 
| So far there doesn't seem to be much enthusiasm for supporting variant
| names in TMCL.

That might be symptomatic of a more general apathy. Or of the fact that most
users of Topic Maps do not (yet) have the same needs as Naito-san.*

| The biggest problem with adding support is that variant
| names have no type, and so it is difficult to see how to express the
| matching part of the constraint. In all other constraints we use
| tmcl:constrain-statement or something similar, but that doesn't work
| for variants.

I hope you excuse me if I say that I don't find this argument particularly
compelling. Surely if a language cannot meet a legitimate requirement, then
there is a problem with the language, not with the requirement?

Unfortunately I don't understand the inner workings of TMCL well enough to be
able to propose a solution. But are you sure you are not trying to create
something more general than is really needed? Would it help if I were to
formulate a constraint in English that I believe would do the job:

  NAMES of type "foo" belonging to
   TOPICS of type "bar" can or must have (one or more)
    VARIANTS in the scope "baz"

In other words, we need to be able to constrain every variant statement on the
basis, not of its type, but of what type of name it is a variant of (and what
type of topic that name belongs to).

Naito-san: Would that satisfy your requirements?

Steve

* In the old days this committee used to bend over backwards to accommodate
everyone with a valid use case - even if they were in a minority.