What steps will reproduce the problem?
1. In Omnigator (5.1.0) load the attached XTM 2.0 topic map which contains a
topic with an untyped base name and a typed base name.
2. Select the topic "topic (without explicitly typed name)" from the Master
3. The topic page you see will show "topic (name type: abbr)" as the name of
the topic at the top of the page instead of "topic (without explicitly typed
name)" as one would expect.
What is the expected output? What do you see instead?
I expected Omnigator to show the untyped name for the topic but Omnigator
doesn't seem to know about http://psi.topicmaps.org/iso13250/model/topic-name .
Please use labels and text to provide additional information.
Also, if you do the following query in Omnigator using the tolog plug-in:
select $T, $TN, $TNT, $TNV
you will see that the default topic name that Omnigator uses isn't the default
name. See the attached tolog output file in CSV format.
Original issue reported on code.google.com by dan.sp...@gmail.com on 11 Sep 2010 at 9:00
It was introduced when we made name types required, but the underlying cause is
that we reproduce the code for this over and over in different modules, for no
I'll draw up a plan for this during the weekend.
Original comment by lar...@gmail.com on 22 Oct 2010 at 1:09
So far this is what i've found:
- The title element is formed using a output:name tag, that uses
Stringificator.toString() which leads to a Stringificator.FastStringifier. This
class prefers names with the default type and produces the correct output
- The topicname in the header is formed using the output:name tag with a scope.
This leads to a GrabberStringifier with a NameGrabber. This NameGrabber's
comparator (TopicNameComparator) still assumes that the default nametype is
'null' and therefor sorts incorrectly causing incorrect output.
- Query results values that are topics are being stringified by
TopicStringifiers.getDefaultStringifier() which uses a GrabberStringifier based
on TopicCharacteristicGrabbers.getDisplayNameGrabber(), which is in turn
another NameGrabber, causing incorrect output.
By fixing the NameGrabber's handling of types I was able to produce correct
output, but this does not solve the problem regarding multiple implementations
I committed the quickfix that solved the original issue and opened issue 429 to
keep track of the duplicate code issue.
Original comment by qsieb...@gmail.com on 18 Nov 2011 at 1:05