[sc34wg3] FW: Supporting variants in TMCL

[Motomu Naito]

Dear Garshol-san,

In the reply to Pepper-san, I made mistake.
Thank you Pepper-san to point out it.

My reply
" In the case of
http://www.infoloom.com/pipermail/topicmapmail/2009q2/007497.html,
if I can constrain variants according to type of NAMES, type of TOPIC and
type of SCOPE,
it meets my requirement I think."

should be

"In the case of
http://www.infoloom.com/pipermail/topicmapmail/2009q2/007497.html,
if I can constrain variants according to type of NAMES, type of TOPIC and
SCOPE,
it meets my requirement I think."

Because SCOPE can't have type.
Sorry if I made you be confused.

Best regards,

Motomu Naito

> Dear Pepper-san,
> 
> On behalf of non-SAE, I greatly appreciate your effort.
> 
> > * 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?
> >
> 
> In the case of
> http://www.infoloom.com/pipermail/topicmapmail/2009q2/007497.html,
> if I can constrain variants according to type of NAMES, type of TOPIC and
> type of SCOPE,
> it meets my requirement I think.
>


> As Gulbrandsen-san says, I would like to read Baldauf-san's paper.
> 
> Best regards,
> 
> Motomu Naito
> 
> > 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.
> >