[sc34wg3] The interpretation of mnemonics
Lars Marius Garshol
27 Apr 2003 13:14:15 +0200
* Steve Pepper
| "Mnemonics" is the collective name I am using for a set of
| attributes on many element types in the HyTM DTD, as follows: [...]
I have to acknowledge that here I've been slightly irresponsible: I
did not create an issue for the representation of mnemonics in the
SAM, as I ought to have done. As a result, the committee has never
discussed this issue formally.
I've rectified that now, and given the issue the ID
| 3. Mnemonics and the 'type' attribute
| Another thing that most mnemonics have in common is that they convey
| essentially the same kind of information as the 'type' attribute on
| the corresponding element.
I would go further and say that they are an informal alternative to
'type'. As such they are much less powerful than 'type' and not at all
conducive to structured information interchange. Personally, I believe
mnemonics should be deprecated; that is, retained in HyTM but users
should be discouraged from using them.
| By "convey the same kind of information" I mean that mnemonics
| are used to express exactly the same semantics as the 'type'
| attribute, but with less flexibility and representational power.
And also with less formality. Mnemonics are essentially informal and
| In addition, the HyTM DTD contains a number of comments stating
| that mnemonics will not be displayed to users if there exists a
| suitable name for the topic referenced by the 'type' attribute.
| So even if one were to use both, e.g.:
| <occurs occrl="email" type="email">
| the 'occrl' attribute could sometimes/often/always be ignored
| (depending on what names the topic with the ID "email" had).
This could be interpreted to mean that if there is a -type- attribute
the -occrl- provides an alternative name for the topic referenced by
the -type- attribute. I think that is a reasonable interpretation.
| On a historical note: The overlap between mnemonics and the
| 'type' attribute, and the greater flexibility and
| representational power of the latter, were the reasons why
| mnemonics were not included in XTM 1.0. I vividly recall one of
| the editors saying at the TopicMaps.Org meeting in Dallas:
| "Mnemonics? What are they? Oh yes, I remember. I've always hated
| those things. Let's get rid of them. People should use topics
| instead." I believe he was absolutely right and have never used
| mnemonics myself.*
We said as much, in our Ontopia comments:
<URL: http://www.ontopia.net/topicmaps/materials/syntax-comments-2000-09.html >
| [...] Perhaps it really was the intention, despite Note 24, that the
| 'linktype' attribute should convey the same kind of information as
| the 'types' attribute. In that case, Note 24 should be regarded as a
| bug and removed.
I think we need input from the editors here. If note 24 is correct
then the -linktype- attribute should remain (for backwards
compatibility), but should have no model significance whatsoever. If
it is not I believe -linktype- should be treated like any other
It would also be useful to hear from the users of HyTM. Both of them.
I suppose you don't use -linktype-, but perhaps Martin does?
| So in practice we can forget about the generic identifiers and just
| focus on the mnemonics.
| Since mnemonics convey the same kind of information as 'type'
| attributes, they should be treated in a similar way. My proposal
| is as follows:
| 1) When both mnemonic and 'type' attributes are present, the
| mnemonic's value should become an additional base name in the
| scope "http://psi.topicmaps.org/hytm/1.0/#mnemonic" on the topic
| referenced by the 'type' attribute.
I agree. (Though we should work out whether it should be 1.0 or
| 2) When only the mnemonic attribute is present, its value should
| become the base name in the scope
| "http://psi.topicmaps.org/hytm/1.1/#mnemonic" of a *new* topic.
Again I agree. Though perhaps we should use name types here to ensure
merging based on the mnemonic.
| That topic should be made the value of the [type] property of
| the information item that corresponds to the element in question.
| I think those are two things we would be better off without,
| but if Martin can present a convincing case for retaining
| mnemonics (I doubt anyone else will even try :-), I'm willing to
| do so based on the proposal above.
I think we should follow your proposal. We should take backwards
compatibility seriously and not throw these things out entirely, but
we should make it clear that their use is discouraged and that later
versions of the standard may get rid of them entirely.
(Personally, I've always detested the things. Geir Ove and I have
always referred to them as "mdemonics". The OKS supports them
directly, and I think that was a bad idea, but we wanted to conform
120% to the standard, and so we kept them in there.)
Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50 <URL: http://www.garshol.priv.no >