tm4j-developers — Forum for issues related to development of TM4J.

[Tm4j-developers] Testcode & CVS

[Norbert H. <rue...@se...>]

Hi,

Gerd & Kal:

There is one issue left on the test code packages. I'm just used
to have parallel packages. There isn't a good reason not to
have nested packages. I think the most important part is to
have a guideline which everybody can agree.

Ok, we'll use subpackages for testcode. package a.b.c will have
a test code package a.b.c.test.

Gerd: it would be nice if you could explain more detailed what
you want to configure via property files.

Kal: If you don't want to check in test code you mentioned earlier
      you can send me a mail

One thing about the offer for cvs access:

Without any good reason I don't really like getting cvs access
right now. I would prefer someone managing code updates for
the next time. this will keep build.xml and similar files tight.
concurrent use isn't critical as long as we work in different
packages. And we can get used to each other :)
If this sounds silly remove it from the log.

sincerely,

Norbert

RE: [Tm4j-developers] Test code

[Kal A. <ka...@te...>]

> >>- test code for package are stored in packages parallel to the packages
> >>to test with
> >>   an test suffix. package a.b.c would have a test package a.b.ctest.
> >>
> >
> > Yes, except that the packages that implement the com.techquila.topicmap
> > interface (com.techquila.topicmap.memory and
> com.techquila.topicmap.ozone)
> > should be tested by the package com.techquila.topicmap.test -
> to validate
> > that the back-end transparency is correct.
> >
> I agree. Test code which tests implementation resides in the implementing
> package while interface test code resides in the interface package.
> you mentioned again the topicmap.test package. The parallel thing is that
> it would be named topicmaptest package. Your strategie would be test code
> in test named subpackages. I stress this a little bit to be sure we are
> talking about the same thing.
>

Oops, yes I missed that. What is the rational for using parallel packages
vs. using nested packages ? I can't see any major difference really and if
there isn't a strong reason for changing to parallel packages I would prefer
not to.

> >
> >>- one additional package as a test suite base. this provides a package
> >>for the main
> >>   test classes and for the classes which are wiring several
> test suites.
> >>
> >>
> >
> > +1 This should include plumbing to enable the selective running
> of tests.
> >
> >
> you mean selective suites? Junit tests are always selectively runnable.
>

Yep, I meant selective suites.

> >>Is this ok?
> >>
> >>
> >
> > Looks really good to me!
> >
> Ok, I will think about the test stuff. I'm trying to create some fixtures
> for general testing.
>

Cool!

> I will start with the simple tests of creating and initializing. This will
> lead to a basic test structure. Kal, when it comes to test the
> processing model
> i will need a lot of your help.
>

No problem. I'll try and be as responsive as I can, although I am going to
be mostly offline from tomorrow until Monday.

> >
> >>What about the package names of the API. Are there any plans to move the
> >>package
> >>naming from com.techquila to org.tm4j ? It isn't really important at the
> >>moment but some things should be clear to everyone who is
> >>contributing code.
> >>This includes the license thing.
> >>
> >>
> >
> > Indeed - I only recently acquired the tm4j.org domain. I've
> been planning
> > that the 0.5 release should be the last release with packages in the
> > techquila.com domain.
> >
> Ok, that sounds very good.
>
> > The license text was changed for the 0.5 release to specify The
> TM4J Project
> > as copyright owner. I would like to add a contributors list to the
> > distribution starting with the next release. Is there something
> more that
> > should be done ?
> >
>
> As long as you are managing the code repository you should declare how the
> code is to be updated. How can someone contribute code? I guess
> you and Gerd
> have write access to the cvs.
> This includes a group policy for deciding who is getting access to cvs
> and when.
> I think there is a lot of bureaucratical things to do. But before
> we really
> start doing more work this seems a little bit of unnecessary overhead.
>

I agree. I had a look at the way that the Apache Project manage this and I
think that in the long run some charter like that of the Apache Software
Foundation would be a useful thing to have.

Right now we have both yourself and Florian willing to add new code to the
TM4J codebase. If Gerd is OK with this I would be happy to grant write
access to both of you - which then gives us a reasonable sized team of
"committers" who can introduce code from other contributors into the
repository. We can then work out a process by which someone can become a
committer at some later date (I believe that a process for this is detailed
in the ASF charter...)

How does that sound ?

Cheers,

Kal

Re: [Tm4j-developers] Test code

[Gerd M. <ge...@sm...>]

Hi,

> > I couldn't agree more! You should find that there is some test code in the
> > CVS tree (src/com/techquila/topicmap/test) which is written using JUnit. But
> > this test code is by no means exhaustive.
> > 
> > I have been working recently on making that test code idependant of which
> > back-end is in use (the memory package or the ozone one) and I don't think I
> > have quite checked in all my changes yet. I'll have a look and check in
> > anything that needs to be.
> > 
> > If you would like to contribute test cases, then the only thing I would ask
> > is that you write them using the JUnit framework (www.junit.org).
> > 
> 
> Junit is also my favourite suite. Additional ant has a junit target that
> makes it easy to include test running in the build process.
> 
> Could we agree on these guidelines:
> 
> - test code is part of the source tree (some tend to divide test code 
> completely)

+1

> - test code for package are stored in packages parallel to the packages 
> to test with
>    an test suffix. package a.b.c would have a test package a.b.ctest.

I would like to use the a.b.c.test variant.

> - one additional package as a test suite base. this provides a package 
> for the main
>    test classes and for the classes which are wiring several test suites.

We should have configurable testcases (I saw already an interface somewhere
in TM4J for that). I've already written such a base test case for another
project. The basic idea was to have a properties file and each testcase
can access the properties of that file.
 
> Is this ok?
> 
> What about the package names of the API. Are there any plans to move the 
> package
> naming from com.techquila to org.tm4j ? It isn't really important at the
> moment but some things should be clear to everyone who is contributing code.
> This includes the license thing.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

Re: [Tm4j-developers] Test code

[Norbert H. <rue...@se...>]

Hi,
>>- test code for package are stored in packages parallel to the packages
>>to test with
>>   an test suffix. package a.b.c would have a test package a.b.ctest.
>>
> 
> Yes, except that the packages that implement the com.techquila.topicmap
> interface (com.techquila.topicmap.memory and com.techquila.topicmap.ozone)
> should be tested by the package com.techquila.topicmap.test - to validate
> that the back-end transparency is correct.
> 
I agree. Test code which tests implementation resides in the implementing
package while interface test code resides in the interface package.
you mentioned again the topicmap.test package. The parallel thing is that
it would be named topicmaptest package. Your strategie would be test code
in test named subpackages. I stress this a little bit to be sure we are
talking about the same thing.

> 
>>- one additional package as a test suite base. this provides a package
>>for the main
>>   test classes and for the classes which are wiring several test suites.
>>
>>
> 
> +1 This should include plumbing to enable the selective running of tests.
> 
> 
you mean selective suites? Junit tests are always selectively runnable.

>>Is this ok?
>>
>>
> 
> Looks really good to me!
>
Ok, I will think about the test stuff. I'm trying to create some fixtures
for general testing.

I will start with the simple tests of creating and initializing. This will
lead to a basic test structure. Kal, when it comes to test the 
processing model
i will need a lot of your help.

> 
>>What about the package names of the API. Are there any plans to move the
>>package
>>naming from com.techquila to org.tm4j ? It isn't really important at the
>>moment but some things should be clear to everyone who is
>>contributing code.
>>This includes the license thing.
>>
>>
> 
> Indeed - I only recently acquired the tm4j.org domain. I've been planning
> that the 0.5 release should be the last release with packages in the
> techquila.com domain.
> 
Ok, that sounds very good.

> The license text was changed for the 0.5 release to specify The TM4J Project
> as copyright owner. I would like to add a contributors list to the
> distribution starting with the next release. Is there something more that
> should be done ?
> 

As long as you are managing the code repository you should declare how the
code is to be updated. How can someone contribute code? I guess you and Gerd
have write access to the cvs.
This includes a group policy for deciding who is getting access to cvs 
and when.
I think there is a lot of bureaucratical things to do. But before we really
start doing more work this seems a little bit of unnecessary overhead.

NoB

RE: [Tm4j-developers] Test code

[Kal A. <ka...@te...>]

> Hi,
> >
> > I couldn't agree more! You should find that there is some test
> code in the
> > CVS tree (src/com/techquila/topicmap/test) which is written
> using JUnit. But
> > this test code is by no means exhaustive.
> >
> > I have been working recently on making that test code
> idependant of which
> > back-end is in use (the memory package or the ozone one) and I
> don't think I
> > have quite checked in all my changes yet. I'll have a look and check in
> > anything that needs to be.
> >
> > If you would like to contribute test cases, then the only thing
> I would ask
> > is that you write them using the JUnit framework (www.junit.org).
> >
>
> Junit is also my favourite suite. Additional ant has a junit target that
> makes it easy to include test running in the build process.
>
> Could we agree on these guidelines:
>
> - test code is part of the source tree (some tend to divide test code
> completely)

+1

> - test code for package are stored in packages parallel to the packages
> to test with
>    an test suffix. package a.b.c would have a test package a.b.ctest.

Yes, except that the packages that implement the com.techquila.topicmap
interface (com.techquila.topicmap.memory and com.techquila.topicmap.ozone)
should be tested by the package com.techquila.topicmap.test - to validate
that the back-end transparency is correct.

> - one additional package as a test suite base. this provides a package
> for the main
>    test classes and for the classes which are wiring several test suites.
>

+1 This should include plumbing to enable the selective running of tests.

> Is this ok?
>

Looks really good to me!

> What about the package names of the API. Are there any plans to move the
> package
> naming from com.techquila to org.tm4j ? It isn't really important at the
> moment but some things should be clear to everyone who is
> contributing code.
> This includes the license thing.
>

Indeed - I only recently acquired the tm4j.org domain. I've been planning
that the 0.5 release should be the last release with packages in the
techquila.com domain.

The license text was changed for the 0.5 release to specify The TM4J Project
as copyright owner. I would like to add a contributors list to the
distribution starting with the next release. Is there something more that
should be done ?


Cheers,

Kal

Re: [Tm4j-developers] Test code

[Norbert H. <rue...@se...>]

Hi,
> 
> I couldn't agree more! You should find that there is some test code in the
> CVS tree (src/com/techquila/topicmap/test) which is written using JUnit. But
> this test code is by no means exhaustive.
> 
> I have been working recently on making that test code idependant of which
> back-end is in use (the memory package or the ozone one) and I don't think I
> have quite checked in all my changes yet. I'll have a look and check in
> anything that needs to be.
> 
> If you would like to contribute test cases, then the only thing I would ask
> is that you write them using the JUnit framework (www.junit.org).
> 

Junit is also my favourite suite. Additional ant has a junit target that
makes it easy to include test running in the build process.

Could we agree on these guidelines:

- test code is part of the source tree (some tend to divide test code 
completely)
- test code for package are stored in packages parallel to the packages 
to test with
   an test suffix. package a.b.c would have a test package a.b.ctest.
- one additional package as a test suite base. this provides a package 
for the main
   test classes and for the classes which are wiring several test suites.

Is this ok?

What about the package names of the API. Are there any plans to move the 
package
naming from com.techquila to org.tm4j ? It isn't really important at the
moment but some things should be clear to everyone who is contributing code.
This includes the license thing.

Enough questions for now,

NoB

RE: [Tm4j-developers] Some news and an idea

[Kal A. <ka...@te...>]

>
> Hi,
>
> first of all I have to mention that it is not my favourite to
> develop GUI programs :) But in lack of having one I decided
> to build one. And I would like to participate in the GUI
> development.
> >
> > That sounds good to me - I was going to suggest that seeing as
> there seem to
> > be a number of people interested in developing this application that it
> > would be a good thing to:
> >
> > a) Split the work up
>
> yes, i think everyone agrees with you. Should we build a detailed
> wishlist to start over?
>

I think that would be the best starting point. I would like to put some
thought into this, but unfortunately I'm in the process of moving house this
weekend so I'm not going to have much time until the middle of next week
now. However, I would ask all others on this list to publish their wishlists
and I'll ask the tm4j-users list for input too.

> > b) Develop the editor as a "framework" into which new GUI tools or
> > processing tools can be easily slotted.
> >
>
> that sounds really nice. Building the GUI Widget upon the Objects they
> are editing it should be easy to include them in a framework. We need
> some structure of distributing single aspects of a map through such
> a framework. I'm very interested in doing such but I don't know enough
> about topic maps and GUIs (as I mentioned last time).
>
>
> > In looking at (b) I think it would be very worthwhile spending some time
> > working out an MVC-style architecture for the application. The
> model part
> > can probably be mostly provided by the existing
> TopicMap/TopicMapProvider
> > interfaces, however it may need some extension to support all of the
> > features required of the editing application. The View and
> Controller parts
> > could draw on some of the "events" in the current version of
> TMNav, though
> > I'm not entirely happy with the structure of that application.
> >
> Could you explain how you think MVC takes place in the application. As
> long as
> we need widgets for topic map objects the widgets will rely heavily on
> using the topic map API. Thus preventing to some extend the use of MVC.
>

That is true to some extent, mostly because GUI widgets such as Swing
widgets really combine View and Controller within  a single object. However,
there are still some aspects of MVC which we should probably assess for
their usefulness such as abstracting selection events so that notification
of selection in one view can be propagated to all other views.

I need to think a little more about this. But getting into this level of
detail before we have the requirements wish-list is probably a bit
premature...

> > Norbert, would it be possible for you to describe the
> architecture of your
> > application a little. Existing applications such as yours and the TMNav
> > application are good starting points for working out a feasible
> architecture
> > for this kind of thing.
> >
> I wouldn't call it application right now :)
> I started to figure out what common functionality could form a
> topic editing
> panel. With comfortable editing in mind I built up three widgets to
> contruct the panel for a topic.
>
> 1.) BaseName and Occurrence. Holding a list of objects. Creation is done
>      from String (textfield input). The creation of those objects is done
>      via a factory which is set up in the widget.
>      -> Constructor(Factory)
> 2.) Occurrence type. Selection of a single Object from a predefined list.
> 3.) BaseName scope, Occurrence Scope, Topic types. Selection of multiple
>      objects from a predefined list.
>
> 2.)+3.)
>
> The selection capabilities are those of a JList. Additional I work with an
> extended ListModel which has search capabilities. This enables the user
> to type in the item he is looking for and the widget autocompletes it.
>
> With the use of a Factory for 1.) and own ListModels and CellRenderers
> for 2.) and 3.) the widgets themself are independent from the tm4j API.
>
> Out of these widgets the topic editing panel is constructed.
>
> Distribution of the topic map and duplicate Method are collected in a
> own class which is itself a Singleton. I don't like the idea but I
> didn't want to make things overcomplicated for me. I will change that
> soon.
>
> Editing an object is really like Kals way in TMNav. There are some
> methods to duplicate topic map objects which then are used in the
> widget for editing. In my opinion this should be a generalized
> functionality in or beside the API (util?).
>

Yes, I think that deep and shallow copy operations would be a really useful
thing to have in a utils package...I shall add it to the TODO list!


>
> It is not much code right now (widgets: 1445 lines, editor 1094 lines).
> I will do more work to have a quite working panel for creation/editing
> of topics and associations.
> In the meantime we could fix some requirements for the GUI.
>
> > And we need a name. Suggestions anyone ? :-)
>
> A really fascinating name would be: *tata* TMEdit *rotfl*
>

That was the only one I could come up with too :-))


Cheers,

Kal

RE: [Tm4j-developers] Test code

[Kal A. <ka...@te...>]

Hi Norbert,

> what about having test code for the API. If we really start
> to build a small framework around topic maps we should
> sure that the base is working, right?
>

Definitely!

> It looks that myself is the one who knows least about
> topic maps right in here. And I love test code. I
> would start to implement a test structure for the
> tm4j API. I think this would be a good work and its
> my chance the learn more about topic maps.
>
> Could anyone agree?
>

I couldn't agree more! You should find that there is some test code in the
CVS tree (src/com/techquila/topicmap/test) which is written using JUnit. But
this test code is by no means exhaustive.

I have been working recently on making that test code idependant of which
back-end is in use (the memory package or the ozone one) and I don't think I
have quite checked in all my changes yet. I'll have a look and check in
anything that needs to be.

If you would like to contribute test cases, then the only thing I would ask
is that you write them using the JUnit framework (www.junit.org).

Cheers,

Kal

[Tm4j-developers] Test code

[Norbert H. <rue...@se...>]

Hi,

what about having test code for the API. If we really start
to build a small framework around topic maps we should
sure that the base is working, right?

It looks that myself is the one who knows least about
topic maps right in here. And I love test code. I
would start to implement a test structure for the
tm4j API. I think this would be a good work and its
my chance the learn more about topic maps.

Could anyone agree?

NoB

Re: [Tm4j-developers] Some news and an idea

[Norbert H. <rue...@se...>]

Hi,

first of all I have to mention that it is not my favourite to
develop GUI programs :) But in lack of having one I decided
to build one. And I would like to participate in the GUI
development.
> 
> That sounds good to me - I was going to suggest that seeing as there seem to
> be a number of people interested in developing this application that it
> would be a good thing to:
> 
> a) Split the work up

yes, i think everyone agrees with you. Should we build a detailed
wishlist to start over?

> b) Develop the editor as a "framework" into which new GUI tools or
> processing tools can be easily slotted.
>

that sounds really nice. Building the GUI Widget upon the Objects they
are editing it should be easy to include them in a framework. We need
some structure of distributing single aspects of a map through such
a framework. I'm very interested in doing such but I don't know enough
about topic maps and GUIs (as I mentioned last time).


> In looking at (b) I think it would be very worthwhile spending some time
> working out an MVC-style architecture for the application. The model part
> can probably be mostly provided by the existing TopicMap/TopicMapProvider
> interfaces, however it may need some extension to support all of the
> features required of the editing application. The View and Controller parts
> could draw on some of the "events" in the current version of TMNav, though
> I'm not entirely happy with the structure of that application.
>
Could you explain how you think MVC takes place in the application. As 
long as
we need widgets for topic map objects the widgets will rely heavily on
using the topic map API. Thus preventing to some extend the use of MVC.

> Norbert, would it be possible for you to describe the architecture of your
> application a little. Existing applications such as yours and the TMNav
> application are good starting points for working out a feasible architecture
> for this kind of thing.
> 
I wouldn't call it application right now :)
I started to figure out what common functionality could form a topic editing
panel. With comfortable editing in mind I built up three widgets to
contruct the panel for a topic.

1.) BaseName and Occurrence. Holding a list of objects. Creation is done
     from String (textfield input). The creation of those objects is done
     via a factory which is set up in the widget.
     -> Constructor(Factory)
2.) Occurrence type. Selection of a single Object from a predefined list.
3.) BaseName scope, Occurrence Scope, Topic types. Selection of multiple
     objects from a predefined list.

2.)+3.)

The selection capabilities are those of a JList. Additional I work with an
extended ListModel which has search capabilities. This enables the user
to type in the item he is looking for and the widget autocompletes it.

With the use of a Factory for 1.) and own ListModels and CellRenderers
for 2.) and 3.) the widgets themself are independent from the tm4j API.

Out of these widgets the topic editing panel is constructed.

Distribution of the topic map and duplicate Method are collected in a
own class which is itself a Singleton. I don't like the idea but I
didn't want to make things overcomplicated for me. I will change that
soon.

Editing an object is really like Kals way in TMNav. There are some
methods to duplicate topic map objects which then are used in the
widget for editing. In my opinion this should be a generalized
functionality in or beside the API (util?).


It is not much code right now (widgets: 1445 lines, editor 1094 lines).
I will do more work to have a quite working panel for creation/editing
of topics and associations.
In the meantime we could fix some requirements for the GUI.

> And we need a name. Suggestions anyone ? :-)

A really fascinating name would be: *tata* TMEdit *rotfl*


NoB

RE: [Tm4j-developers] Some news and an idea

[Kal A. <ka...@te...>]

>
> Hello!
>
> [Kal]
> | That doesn't sound too onerous to me...email / snail mail
> communication is
> | fine - I just couldn't commit to travelling to Austria for a
> meeting (then
> | again, that might not be such a bad thing... ;-)
> |
> | I would be really happy to see this go ahead if you can make it happen
> | Florian! I'll do whatever I can to help out with your administration.
>
> I take that as a go! :-) I'll go ahead and see what I can do.
>
> [Norbert]
> | [...] at the moment I'm trying to build a editing gui to create/manage
> | topic maps. [...]
>
> Kal, Gerd, what do you guys think of that? Taking into account
> that I don't
> really consider myself a GUI guru, wouldn't this be a nice way of sharing
> the workload for a TM4J-based TM editing application, me doing the DOM
> framework and Norbert doing the front end?
>

That sounds good to me - I was going to suggest that seeing as there seem to
be a number of people interested in developing this application that it
would be a good thing to:

a) Split the work up
b) Develop the editor as a "framework" into which new GUI tools or
processing tools can be easily slotted.

In looking at (b) I think it would be very worthwhile spending some time
working out an MVC-style architecture for the application. The model part
can probably be mostly provided by the existing TopicMap/TopicMapProvider
interfaces, however it may need some extension to support all of the
features required of the editing application. The View and Controller parts
could draw on some of the "events" in the current version of TMNav, though
I'm not entirely happy with the structure of that application.

Norbert, would it be possible for you to describe the architecture of your
application a little. Existing applications such as yours and the TMNav
application are good starting points for working out a feasible architecture
for this kind of thing.

And we need a name. Suggestions anyone ? :-)

Cheers,

Kal

RE: [Tm4j-developers] Some news and an idea

[Florian G. H. <f.g...@gm...>]

Hello!

[Kal]
| That doesn't sound too onerous to me...email / snail mail communication is
| fine - I just couldn't commit to travelling to Austria for a meeting (then
| again, that might not be such a bad thing... ;-)
|
| I would be really happy to see this go ahead if you can make it happen
| Florian! I'll do whatever I can to help out with your administration.

I take that as a go! :-) I'll go ahead and see what I can do.

[Norbert]
| [...] at the moment I'm trying to build a editing gui to create/manage
| topic maps. [...]

Kal, Gerd, what do you guys think of that? Taking into account that I don't
really consider myself a GUI guru, wouldn't this be a nice way of sharing
the workload for a TM4J-based TM editing application, me doing the DOM
framework and Norbert doing the front end?

Later,
-- Florian

----------------------------------------------
Florian G. Haas
FHS Informationsberufe, Eisenstadt, Austria
http://info.fh-eisenstadt.ac.at/~haasf/

Re: [Tm4j-developers] Some news and an idea

[Norbert H. <rue...@se...>]

Hi,

 > I would love to see some serious development go into a navigation/editing
 > tool. I think that such a tool could cover all kinds of interesting 
areas -
 > visualisation techniques, topic map "templates" or "schemas" for easier
 > editing, form-driven editing (perhaps using XUL ?), as well as 
integrating
 > querying and automatic topic map generation tools. Lots of scope for 
lots of
 > interesting stuff.
 >

at the moment I'm trying to build a editing gui to create/manage topic maps.
While this is my first project using swing/GUI progress is really really
slow (I restarted the complete code for the fourth time now).
I also struggle with topic maps a little bit. I got in touch with it
already but there are a lot of nuts & bolts to solve.

But thats only excuses :)

My plans for the gui are at the moment.

- creation of editing panels for topics and associations
- figuring out what additional aspects should be handled
    by the gui
- load and save capabilities of maps
- using ozone package


future plans:

- remote editing capabilities. the gui could should be able to
   work on a local xtm file or ozone database and also
   connect to a remote server to update/edit a map
- preview mode in gui. basic structure of the map should
   be viewable and navigatable


If there are any ideas/suggestions/plans what the GUI should contain
I'm very interested to hear that.

thats for now,

NoB

RE: [Tm4j-developers] Some news and an idea

[Kal A. <ka...@te...>]

> Hi all.
>
> [Gerd]
> | > Now, all of this is, as of yet, totally unofficial, and if at all
> | > possible, will definitely require a lot of negotiation with the
> | > college on my part and a bit of paperwork on your part. But I would
> |
> | Which kind of paperwork ?
>
> In essence, there would be something like a project charter that I would
> have to draft, a person representing the "partner organization" (for the
> TM4J project, this would presumably be Kal) would have to
> approve, and which
> would be filed with my college's administration. But perhaps there would
> also be some e-mail traffic to and fro since our administration might want
> to clarify some things with the "partner organization
> representative" before
> giving the green light for the project. Be advised, however, that I'm
> speculating here. They might clear everything without any hassle involved,
> or they might get rellay inquisitive. You never know. I know this isn't
> exactly reassuring, but I think honesty is going to get us further than --
> Gerd, help me out, what's a good English term for "Schonfarberei"?
>

That doesn't sound too onerous to me...email / snail mail communication is
fine - I just couldn't commit to travelling to Austria for a meeting (then
again, that might not be such a bad thing... ;-)

I would be really happy to see this go ahead if you can make it happen
Florian! I'll do whatever I can to help out with your administration.

Cheers,

Kal

RE: [Tm4j-developers] Some news and an idea

[Kal A. <ka...@te...>]

>
> Hi Florian,
>
> > Kal, Gerd, I have some news I'd like to mention to you. Not about any
> > progress on the TM4J DOM package (yet), but perhaps worth discussing.
> >
> > OK, the initial news is that I'm back from 3 weeks of training. I
> > have a few certification exams left to take, but at least I'm no
> > longer occupied 100% of the day. So I should be able to make more
> > time for TM4J in the weeks to come, and we'll see some progress on
> > the DOM package in the foreseeable future.
> >
> > The other news is that my current project just bombed. I've been
> > working on a knowledge management project, TM-related, since
> > February. This started out as a college initiative (the "applied
> > science" bit, you know), and was about to be continued as such -- and
> > to hit commercial development -- this fall. Yesterday, two of the
> > five developers involved informed the rest of the team that they were
> > no longer interested (contrary to commitments they had made just
> > three weeks before), and the partner organization is more than likely
> > to go ahead and pursue the same thing with some other development
> > team. Bottom line for me is, I'm out. Bummer.
> >
> > Now, I'm in a situation where a) I don't have a TM project on my
> > hands and b) I don't have a college project on my hands (the latter
> > is mandatory for my coming two semesters). I don't like either of
> > these two facts. :-) Now, I would like to know from you what you are
> > thinking about the following ideas:
> >
> > * For the record, delegate a specific pending task in the TM4J
> > project to me (e.g. work on the DOM package, if we want that),
>
> I don't mind. I guess there also the part of the navigation tool left
> open. Another idea is a query language. I've already started the
> implementation of the Tolog query language, but there are still lot of
> things to do.
>

I would love to see some serious development go into a navigation/editing
tool. I think that such a tool could cover all kinds of interesting areas -
visualisation techniques, topic map "templates" or "schemas" for easier
editing, form-driven editing (perhaps using XUL ?), as well as integrating
querying and automatic topic map generation tools. Lots of scope for lots of
interesting stuff.

> > * File that task as a one-man project with my college (FHS
> > Informationsberufe, Eisenstadt, Austria) with a projected 200
> > man-hours total amount of work -- that's the default for what they
> > consider a 9-month project, believe it or not. The number is totally
> > ludicrous, and is one of dozens of strange rules imposed by our PHB.
> > They always want lots of paper, status reports, and MS project files
> > to make the whole thing look like what they think is a professional
> > project.
> >
> > Now, all of this is, as of yet, totally unofficial, and if at all
> > possible, will definitely require a lot of negotiation with the
> > college on my part and a bit of paperwork on your part. But I would
>
> Which kind of paperwork ?
>
> > like to know if, provided I manage to get all obstacles out of the
> > way, you would be interested in actually taking that course of
> > action.
> >
> > I fully understand that all this is happening a bit suddenly -- after
> > all, I've appeared in the TM4J project out of the blue just a few
> > weeks ago and none of you have had the chance of really getting to
> > know me. So absolutely no hard feelings if I get a no-go. :-) But if
> > you guys are thinking this is a feasible idea, please let me know as
> > soon as you can. I'd have to start contacting the college
> > administration ASAP and see if I can get them to approve. My classes
> > start on September 17, and if we want to do this, I should aim at
> > reaching some sort of productive stage by October 1.
>
> Best Regards,
> Gerd
>
> --
> ________________________________________________________________
> Gerd Mueller                                    ge...@sm...
> SMB GmbH                                  http://www.smb-tec.com
>
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> http://lists.sourceforge.net/lists/listinfo/tm4j-developers
>
>

Re: [Tm4j-developers] Some news and an idea

[Gerd M. <ge...@sm...>]

On Mon, 27 Aug 2001 10:47:37 +0200
"Florian G. Haas" <f.g...@gm...> wrote:

> Hi all.
> 
> [Gerd]
> | > Now, all of this is, as of yet, totally unofficial, and if at all
> | > possible, will definitely require a lot of negotiation with the
> | > college on my part and a bit of paperwork on your part. But I would
> |
> | Which kind of paperwork ?
> 
> In essence, there would be something like a project charter that I would
> have to draft, a person representing the "partner organization" (for the
> TM4J project, this would presumably be Kal) would have to approve, and which
> would be filed with my college's administration. But perhaps there would
> also be some e-mail traffic to and fro since our administration might want
> to clarify some things with the "partner organization representative" before
> giving the green light for the project. Be advised, however, that I'm
> speculating here. They might clear everything without any hassle involved,
> or they might get rellay inquisitive. You never know. I know this isn't
> exactly reassuring, but I think honesty is going to get us further than --
> Gerd, help me out, what's a good English term for "Schonfarberei"?

'nice painting' ? ;-) No, leo says 'to whitewash smth.'  
or 'to gloss over smth.'.

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

RE: [Tm4j-developers] Some news and an idea

[Florian G. H. <f.g...@gm...>]

Hi all.

[Gerd]
| > Now, all of this is, as of yet, totally unofficial, and if at all
| > possible, will definitely require a lot of negotiation with the
| > college on my part and a bit of paperwork on your part. But I would
|
| Which kind of paperwork ?

In essence, there would be something like a project charter that I would
have to draft, a person representing the "partner organization" (for the
TM4J project, this would presumably be Kal) would have to approve, and which
would be filed with my college's administration. But perhaps there would
also be some e-mail traffic to and fro since our administration might want
to clarify some things with the "partner organization representative" before
giving the green light for the project. Be advised, however, that I'm
speculating here. They might clear everything without any hassle involved,
or they might get rellay inquisitive. You never know. I know this isn't
exactly reassuring, but I think honesty is going to get us further than --
Gerd, help me out, what's a good English term for "Schonfarberei"?

Later,
-- Florian

----------------------------------------------
Florian G. Haas
FHS Informationsberufe, Eisenstadt, Austria
http://info.fh-eisenstadt.ac.at/~haasf/

Re: [Tm4j-developers] Some news and an idea

[Gerd M. <ge...@sm...>]

Hi Florian,

> Kal, Gerd, I have some news I'd like to mention to you. Not about any
> progress on the TM4J DOM package (yet), but perhaps worth discussing.
> 
> OK, the initial news is that I'm back from 3 weeks of training. I
> have a few certification exams left to take, but at least I'm no
> longer occupied 100% of the day. So I should be able to make more
> time for TM4J in the weeks to come, and we'll see some progress on
> the DOM package in the foreseeable future.
> 
> The other news is that my current project just bombed. I've been
> working on a knowledge management project, TM-related, since
> February. This started out as a college initiative (the "applied
> science" bit, you know), and was about to be continued as such -- and
> to hit commercial development -- this fall. Yesterday, two of the
> five developers involved informed the rest of the team that they were
> no longer interested (contrary to commitments they had made just
> three weeks before), and the partner organization is more than likely
> to go ahead and pursue the same thing with some other development
> team. Bottom line for me is, I'm out. Bummer.
> 
> Now, I'm in a situation where a) I don't have a TM project on my
> hands and b) I don't have a college project on my hands (the latter
> is mandatory for my coming two semesters). I don't like either of
> these two facts. :-) Now, I would like to know from you what you are
> thinking about the following ideas: 
> 
> * For the record, delegate a specific pending task in the TM4J
> project to me (e.g. work on the DOM package, if we want that),

I don't mind. I guess there also the part of the navigation tool left 
open. Another idea is a query language. I've already started the
implementation of the Tolog query language, but there are still lot of
things to do.

> * File that task as a one-man project with my college (FHS
> Informationsberufe, Eisenstadt, Austria) with a projected 200
> man-hours total amount of work -- that's the default for what they
> consider a 9-month project, believe it or not. The number is totally
> ludicrous, and is one of dozens of strange rules imposed by our PHB.
> They always want lots of paper, status reports, and MS project files
> to make the whole thing look like what they think is a professional
> project.
> 
> Now, all of this is, as of yet, totally unofficial, and if at all
> possible, will definitely require a lot of negotiation with the
> college on my part and a bit of paperwork on your part. But I would

Which kind of paperwork ?

> like to know if, provided I manage to get all obstacles out of the
> way, you would be interested in actually taking that course of
> action.
> 
> I fully understand that all this is happening a bit suddenly -- after
> all, I've appeared in the TM4J project out of the blue just a few
> weeks ago and none of you have had the chance of really getting to
> know me. So absolutely no hard feelings if I get a no-go. :-) But if
> you guys are thinking this is a feasible idea, please let me know as
> soon as you can. I'd have to start contacting the college
> administration ASAP and see if I can get them to approve. My classes
> start on September 17, and if we want to do this, I should aim at
> reaching some sort of productive stage by October 1.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

[Tm4j-developers] Some news and an idea

[Florian G. H. <f.g...@gm...>]

Hello.

Kal, Gerd, I have some news I'd like to mention to you. Not about any
progress on the TM4J DOM package (yet), but perhaps worth discussing.

OK, the initial news is that I'm back from 3 weeks of training. I
have a few certification exams left to take, but at least I'm no
longer occupied 100% of the day. So I should be able to make more
time for TM4J in the weeks to come, and we'll see some progress on
the DOM package in the foreseeable future.

The other news is that my current project just bombed. I've been
working on a knowledge management project, TM-related, since
February. This started out as a college initiative (the "applied
science" bit, you know), and was about to be continued as such -- and
to hit commercial development -- this fall. Yesterday, two of the
five developers involved informed the rest of the team that they were
no longer interested (contrary to commitments they had made just
three weeks before), and the partner organization is more than likely
to go ahead and pursue the same thing with some other development
team. Bottom line for me is, I'm out. Bummer.

Now, I'm in a situation where a) I don't have a TM project on my
hands and b) I don't have a college project on my hands (the latter
is mandatory for my coming two semesters). I don't like either of
these two facts. :-) Now, I would like to know from you what you are
thinking about the following ideas: 

* For the record, delegate a specific pending task in the TM4J
project to me (e.g. work on the DOM package, if we want that),
* File that task as a one-man project with my college (FHS
Informationsberufe, Eisenstadt, Austria) with a projected 200
man-hours total amount of work -- that's the default for what they
consider a 9-month project, believe it or not. The number is totally
ludicrous, and is one of dozens of strange rules imposed by our PHB.
They always want lots of paper, status reports, and MS project files
to make the whole thing look like what they think is a professional
project.

Now, all of this is, as of yet, totally unofficial, and if at all
possible, will definitely require a lot of negotiation with the
college on my part and a bit of paperwork on your part. But I would
like to know if, provided I manage to get all obstacles out of the
way, you would be interested in actually taking that course of
action.

I fully understand that all this is happening a bit suddenly -- after
all, I've appeared in the TM4J project out of the blue just a few
weeks ago and none of you have had the chance of really getting to
know me. So absolutely no hard feelings if I get a no-go. :-) But if
you guys are thinking this is a feasible idea, please let me know as
soon as you can. I'd have to start contacting the college
administration ASAP and see if I can get them to approve. My classes
start on September 17, and if we want to do this, I should aim at
reaching some sort of productive stage by October 1.

I'd be pleased to read your comments,
-- Florian

----------------------------------------------
Florian G. Haas
FHS Informationsberufe, Eisenstadt, Austria
http://info.fh-eisenstadt.ac.at/~haasf/

RE: [Tm4j-developers] Proposal for new TM4J package [Long]

[Florian G. H. <f.g...@gm...>]

Hi!

[Gerd]
| Seems an interesting approach to me and it has to be evaluated in a real
| application. So, we should give it a try.
|
| A technical issue: How do you map the graph structure into a tree ? E.g.
| if I want the type of an association, which referenced by an ID in XTM, do
| you start than an XPath query ?

Precisely. One would then extract the desired topic ID from the xlink:href
attribute of the <topicRef> inside the <instanceOf>, and create the XPath
expression using that. So if there's an association whose <instanceOf>
refers to a topic with the id "foobar" in the current topic map
(xlink:href="#foobar"), the XPath expression becomes "/topicMap/topic[@id =
'foobar']".

This could also be used for trickier problems such as finding all <variant>s
whose <parameters> refer to a certain topic, as in
"//variant[parameters/topicRef/@xlink:href = '#foobar']", thereby scanning
the DOM tree recursively for matching elements. Or just scan for whatever
refers to a certain topic, as in "//topicRef[@xlink:href = 'foobar']".

Later,
-- Florian

Re: [Tm4j-developers] Proposal for new TM4J package [Long]

[Gerd M. <ge...@sm...>]

On Wednesday 08 August 2001 10:59, you wrote:
> Hi all,
>
> You will probably have seen the recent posting from Florian Haas about work
> he has done on implementing the TM4J API on top of a DOM representation of
> an XTM document. The approach he has taken is interesting in a number of
> respects:
>
> 1) The use of XPath queries to provide the topic map indexes
> 2) The maintenance of an underlying data structure (the DOM) which much
> more closely represents the source XTM file being processed.
>
> My feeling is that were this package to be developed, it would provide a
> robust foundation for building a topic map editing package that can do some
> of the useful editor-type things that the existing in-memory package could
> not do. For example, the DOM implementation could be made to preserve
> element ordering, and so preserve toppic map elements on a "round-trip"
> editing cycle...this is something which would be a big advantage for manual
> editing. Also, having an integration with an XPath processor would enable
> an editor to construct arbitrary queries quite easily.
>
> Florian and I have discussed how this package relates to the existing
> in-memory implementation and I think that this package has strengths that
> make it ideally suited for building an editing environment.
>
> As a new project team, we don't really have a "process" for introducing new
> packages into the project. Perhaps at some stage in the future we should
> formalise the process...however, right now I am interested in hearing what
> the views of the other members of this list are. The main question is "Does
> this sound like something that should be a part of TM4J ?"...the second
> question is "Is it something that you feel you could / would help out with
> ?"

Seems an interesting approach to me and it has to be evaluated in a real 
application. So, we should give it a try. 

A technical issue: How do you map the graph structure into a tree ? E.g.
if I want the type of an association, which referenced by an ID in XTM, do
you start than an XPath query ?

Best Regards,
Gerd

[Tm4j-developers] Proposal for new TM4J package [Long]

[Kal A. <ka...@te...>]

Hi all,

You will probably have seen the recent posting from Florian Haas about work
he has done on implementing the TM4J API on top of a DOM representation of
an XTM document. The approach he has taken is interesting in a number of
respects:

1) The use of XPath queries to provide the topic map indexes
2) The maintenance of an underlying data structure (the DOM) which much more
closely represents the source XTM file being processed.

My feeling is that were this package to be developed, it would provide a
robust foundation for building a topic map editing package that can do some
of the useful editor-type things that the existing in-memory package could
not do. For example, the DOM implementation could be made to preserve
element ordering, and so preserve toppic map elements on a "round-trip"
editing cycle...this is something which would be a big advantage for manual
editing. Also, having an integration with an XPath processor would enable an
editor to construct arbitrary queries quite easily.

Florian and I have discussed how this package relates to the existing
in-memory implementation and I think that this package has strengths that
make it ideally suited for building an editing environment.

As a new project team, we don't really have a "process" for introducing new
packages into the project. Perhaps at some stage in the future we should
formalise the process...however, right now I am interested in hearing what
the views of the other members of this list are. The main question is "Does
this sound like something that should be a part of TM4J ?"...the second
question is "Is it something that you feel you could / would help out with
?"

I look forward to hearing your thoughts. [The email discussion between
Florian and myself is copied at the end of this email].

Cheers,

Kal

-----------------------------------
Kal Ahmed
XML and Topic Maps Consultant
e: ka...@te...
p: +44 (0)7968 529 531
w: www.techquila.com
-----------------------------------



>
> Hi Kal,
>
> | Firstly, thanks for telling me about this development!
>
> No sweat at all. You're very welcome. :-)
>
> | I like the use of the XPath evaluations to provide the indexing.
>
> Well, I do think it's a nice approach, although I'm not too happy with the
> way I've implemented it so far -- it's actually quite quick and dirty. I
> think I could get this to run a lot more elegantly if I evaluated
> the XPath
> expression by some other means than using the static methods in
> the XPathAPI
> class. But for now, it's all "go with what works".
>

Always the best way ;-)

> | I suppose that theoretically, this DOM implementation could be layered
> over any
> | persistent storage mechanism that provides a DOM interface, right ?
>
> Honestly: when I started on this I was merely playing with TM4J and
> something like "implementing this using the DOM would be nice". Just the
> let's-see-if-this-can-be-done type of thing, so now real worries
> if there is
> any real applicability in life. :-) But what you are saying
> certainly makes
> sense.
>

It would be interesting to see if the DOM implementation can play with one
of the XML databases that provides a DOM interface. The Ozone database which
TM4J uses to provide a persistent backend is also used by another project
which layers XML content management on the database - perhaps that might be
an interesting starting point...

> | I aslo thing that if you can work out a way to make application of the
> topic naming constraint and topic
> | merging in general work without modifying the DOM tree [...]
>
> Not quite sure what you mean by "without modifying the DOM tree".
> Say I have
> a topic that's already in the tree, and the tree already represents a
> consistent TM. Now I want to add a new topic, which has the same base name
> in the same scope as that existing topic. Classic case of TNC-based merge:
> REMOVE existing topic, ADD merged topic. That's modifying the
> tree, right? I
> take nodes out and I put nodes in. How should I do this without modifying
> the tree? Please clarify.
>

What you describe is what should "logically" happen to the topic map,
however, an application should be free to "physically" implement that in any
way it sees fit. For example, if topic A merges with topic B, TM4J does not
remove either topic, instead it makes B a "merged topic" of A. All topics
know their list of merged topics and all merged topics know which topic they
are merged with. This means that any topic, when asked for its
characteristics (such as its names or occurrences) can actually return a
collection containing the values of all of the topics it is merged with. So
logically, it looks to an application as if A and B were merged, physically,
they are separate and using the API it is possible to get at A and B and
modify them separately and even to modify them in such a way that they
"unmerge" and go back to being separate topics again.

This kind of functionality would be incredibly useful in an editing
environment where a merge may happen because the user enters a name string
which happens to be used by another topic. And from an editors point of
view, I think it would be nice to have a file round-trip all <topic>
elements regardless of whether they merge when processed or not...

> | [...]  becaues the application would then be able to guaruntee
> to maintain
> the
> | ordering of the XTM elements (something which the
> com.techquila.topicmap.memory
> | package cannot do).
>
> An com.techquila.topicmap.dom can't yet, either. For example,
> currently, if
> I want to add a scope to a base name that already contains a base name
> string, the DOM implementation simply appends the new <scope> AFTER the
> existing <baseNameString>, which makes the whole TM no longer valid XTM.
> Needless to say, this has to get fixed. And it will. :-)
>

We all have to start somewhere! :-)

> | So my gut feeling is that this implementation is most especially useful
> for editing
> | apps - does that sound right to you ?
>
> Sounds good! Again, this is a classic let's-see-if-this-works venture.
> Compare this to a paragraph above; you'll see a pattern emerging here. :-)
> To be frank, this whole thing was like, OK, I'll give it a shot, as far as
> applicability is concerned -- that's where Kal comes in. And you did! :-)
> Kind of a naive approach, I know.
>
> | In principle, I would have nothing at all against including this
> | as part of
> | the TM4J Project if we can make a clear distinction between what the dom
> | package is intended to do and what the memory package is intended to do.
>
> Well, I guess that distinction is easily made. Firstly, I suppose (gut
> feeling) that the DOM implementation trades perhaps enhanced
> flexibility for
> a major overhead. Just take a look at the object hierarchy. I would assume
> that the in-memory implementation is lightning fast and extremely
> lightweight by comparison. Secondly, for the time being, the DOM
> implementation is at best pre-experimental and far from even half-way
> complete. Its worst down side is, I guess, the lack of a parser. Anyway,
> everything is really under major construction, as I'm sure you've noticed.
>
> Now if you want a formal "yes, I'd like to join the development
> effort", you
> have it. But please be advised, as I already wrote, that my time is
> extremely limited in the next three weeks, so I doubt that I'll be making
> any progress during that time. After that, I can get things going again.
>

That would be cool. I would like to copy this message over to the TM4J
Developer's list, and propose it as a new sub-project for TM4J. Is that OK
with you ? (I'm making it sound like we have some formal process...but we
don't I would just like it to be discussed in that forum too).

I'm in favour of adding this in as a foundation for building an editing
environment that I think would provide useful features such as element-level
round-tripping and arbitrary XPath expression evaluation. If the others
agree (there are only two of us currently active developers), then I would
be happy to add you in to the development team and you can then upload your
code to CVS whenever you feel ready.

How does that sound ?

Kal

[Tm4j-developers] About to join the development effort

[Florian G. H. <f.g...@gm...>]

Hello!

Since this is my first appearance on this list, please allow me to introduce
myself.

My name is Florian; I'm currently a student at Fachhochschul-Studiengang
Informationsberufe (a college of applied science in information technology
and knowledge management) in Eisenstadt, Austria. My technical background is
mainly one of a Java aficionado and relational database designer (Oracle,
SQL Server). I came across Topic Maps and XTM in late January of this year;
what intrigues me most about the whole concept is its flexibility and
elegance in terms of describing knowledge concepts and interconnections
between them -- so much nicer than what we find in most RDBMS-based
information systems. :-)

I have exchanged a few ideas about a DOM implementation of the TM4J engine
with Kal in the past few days; I guess he's going to post a digest of our
conversation to this list soon. In the meantime, you perhaps would like to
take a look at what's already there; for the time being, it's on my personal
web site at http://www.fgh.bkf.at/personal/stuff/tm4j/. Beware, though, all
of this is really pre-pre-pre-alpha. :-)

Enough said for now. I suppose Kal will say the rest.

Later,
-- Florian

RE: [Tm4j-developers] Normalising ID and resourceID

[Kal A. <ka...@te...>]

>
> > I've been reviewing the way in which TM4J's import and export
> functionality
> > handles the resolution and normalisation of IDs and references
> and I would
> > like to get feedback on my thoughts before implementing anything.
> >
> > Firstly, all TopicMapObjects have two separate 'identifiers':
> >
> >   ID property: Assigned by the import process.
> >                Guarunteed to be unique across all objects in the same
> > TopicMap
> >                Should be stored as the ID only (not as a full URL)
> >
> >   resourceID property: The URI of the XML element which gave rise to the
> > creation
> >                          of the object.
> >                        Stored as a complete URI (many different
> topic map
> > documents
> >                          may contribute objects to a single TopicMap.
> >                        May be NULL
> >                        Guarunteed to be unique across all objects in the
> > same TopicMap.
> >
> > Then TopicMaps have three additional associated URIs:
> >
> >   baseURL property: The URL which should be treated as the URL
> of the topic
> > map in
> >                       its entirety. All objects in the topic
> map can then be
> >                       addressed as <baseURL>#<ID>.
> >                     This is currently not a required property of the
> > TopicMap, but
> >                       it probably should be.
> >
> >   xml:base : The (optional) value of the xml:base attribute of the
> >                <topicMap> element.
> >              Used only during parsing to resolve references to external
> > documents.
> >
> >   sourceURL: Not stored as a property of the TopicMap, but just
> used when
> > parsing
> >                a source document.
> >              Used only during parsing to resolve the value of the id
> > attribute
> >                of an element into a full URI for storing as the
> resourceID
> >                property of a TopicMapObject
> >              Used to resolve references to external documents
> if baseURL is
> > not
> >                specified
> >
> > Addressing into a topic map held in a TM4J system may require a
> > backend-specific URI to identify the store. However, once a
> connection is
> > made to a TM4J store, I think it should be possible to query the
> > TopicMapProvider interface to retrieve a TopicMapObject by
> specifying a URL
> > constructed of the baseURL property of the TopicMap and the ID
> of the object
> > required.
> >
> > What I have described in the foregoing is not exactly the way that TM4J
> > behaves right now, partially because I didn't properly understand the
> > purpose of xml:base and partly because before the Ozone implementation,
> > there was no real need to consider a TM4J system that kept
> track of multiple
> > topic maps simultaneously.
> >
> > So, my questions to y'all are: Does this sound reasonable to
> everyone ? Is
> > there something else missing from this list ?
>
> One problem that I see is when to use the ID and when the resourceID.
> I mean if I reference a topic in another topicmap I would write
> <baseURL of th TM>#<ID of the topic>. But could it also be possible
> to use the resourceID instead of the ID ? And if so, how do we
> differentiate both versions or is this up to the target topic map ?
>

The problem is that one TopicMap object could be generated from multiple XTM
files, and so it will actually contain a set of resourceIDs from each of the
different document bases.
It is definitely necessary for references to be able to use resourceID as
easily as possible as those should be considered to be the "external" ID of
the object - and are the only ID that the topic map author has some control
over before TM4J processes the topic map.

> We could say the <baseURL>#<some id> means that <some id> is an ID
> and <xml:base URL>#<some id> means that <some id> is a resourceID.
> But the baseURL and <xml:base> can be the same, e.g. if there is
> no <xml:base> in the XTM file. The solution could a different
> syntax for both versions, e.g. <baseURL>/ID#<some ID> references
> the ID of topic and <baseURL>#<some ID> the resourceID.
>

This could be a neat way of working. Again, I would be in favour of not
munging the resourceIDs. So I would suggest that you access a topic map
object by resourceID by simply asking for the full URL of the resource. To
access by ID use <topic map baseURL>?id=<ID>.

What this means in practice is that topic map authors will probably always
use the resourceID form of reference when working with XTM files locally,
but may prefer to use the TopicMapObject ID form of reference when creating
an XTM file that is to be merged with a topic map already stored in a TM4J
server. Obviously, the second form of reference really only makes sense with
a persistent store.

What I like about this approach is that it could then be extended a little
further to handle a "topic map server" application managing multiple topic
maps so that the URL <topic map server base>?topicmap=<topicmap
id>&id=<object ID> could be mapped by the topic map server into <topic map
baseURL>?id=<ID>

> We could also say that if there is a resourceID given by the XTM
> file then the ID of the topic must be the same as the resourceID.
> But then it will be hard to insure the uniqueness if the ID.
>

I would prefer not to have to enforce unique IDs across all possible source
XTM files. It could make life very difficult for applications which are
combining multiple XTM files from different sources.

Cheers,

Kal

Re: [Tm4j-developers] Normalising ID and resourceID

[Gerd M. <ge...@sm...>]

> I've been reviewing the way in which TM4J's import and export functionality
> handles the resolution and normalisation of IDs and references and I would
> like to get feedback on my thoughts before implementing anything.
> 
> Firstly, all TopicMapObjects have two separate 'identifiers':
> 
>   ID property: Assigned by the import process.
>                Guarunteed to be unique across all objects in the same
> TopicMap
>                Should be stored as the ID only (not as a full URL)
> 
>   resourceID property: The URI of the XML element which gave rise to the
> creation
>                          of the object.
>                        Stored as a complete URI (many different topic map
> documents
>                          may contribute objects to a single TopicMap.
>                        May be NULL
>                        Guarunteed to be unique across all objects in the
> same TopicMap.
> 
> Then TopicMaps have three additional associated URIs:
> 
>   baseURL property: The URL which should be treated as the URL of the topic
> map in
>                       its entirety. All objects in the topic map can then be
>                       addressed as <baseURL>#<ID>.
>                     This is currently not a required property of the
> TopicMap, but
>                       it probably should be.
> 
>   xml:base : The (optional) value of the xml:base attribute of the
>                <topicMap> element.
>              Used only during parsing to resolve references to external
> documents.
> 
>   sourceURL: Not stored as a property of the TopicMap, but just used when
> parsing
>                a source document.
>              Used only during parsing to resolve the value of the id
> attribute
>                of an element into a full URI for storing as the resourceID
>                property of a TopicMapObject
>              Used to resolve references to external documents if baseURL is
> not
>                specified
> 
> Addressing into a topic map held in a TM4J system may require a
> backend-specific URI to identify the store. However, once a connection is
> made to a TM4J store, I think it should be possible to query the
> TopicMapProvider interface to retrieve a TopicMapObject by specifying a URL
> constructed of the baseURL property of the TopicMap and the ID of the object
> required.
> 
> What I have described in the foregoing is not exactly the way that TM4J
> behaves right now, partially because I didn't properly understand the
> purpose of xml:base and partly because before the Ozone implementation,
> there was no real need to consider a TM4J system that kept track of multiple
> topic maps simultaneously.
> 
> So, my questions to y'all are: Does this sound reasonable to everyone ? Is
> there something else missing from this list ?

One problem that I see is when to use the ID and when the resourceID.
I mean if I reference a topic in another topicmap I would write
<baseURL of th TM>#<ID of the topic>. But could it also be possible
to use the resourceID instead of the ID ? And if so, how do we
differentiate both versions or is this up to the target topic map ?

We could say the <baseURL>#<some id> means that <some id> is an ID
and <xml:base URL>#<some id> means that <some id> is a resourceID.
But the baseURL and <xml:base> can be the same, e.g. if there is
no <xml:base> in the XTM file. The solution could a different 
syntax for both versions, e.g. <baseURL>/ID#<some ID> references
the ID of topic and <baseURL>#<some ID> the resourceID.

We could also say that if there is a resourceID given by the XTM
file then the ID of the topic must be the same as the resourceID.
But then it will be hard to insure the uniqueness if the ID.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com