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

Re: [Tm4j-developers] One doubt

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

Hi Gautham,

According to the XTM specification, the <instanceOf> tag when used to 
specify the "type" of  topic is equivalent to creating an association of 
the type "class-instance" between the two topics with the "type" topic 
playing the role "class" and the other topic playing the role "instance". A 
compliant XTM processor is required to recognise this and (in my 
interpretation of the spec) be able to present this association to a 
calling program if it asks for it. Now, because this association type and 
the role types are defined by Published Subject Indicators (PSIs), TM4J 
must create topics for these PSIs in order for the topic map to be 
internally complete. That is why three extra topics get created.

By default, the TopicMapWalker object will not export these additional 
associations (though you can set it to do so by calling 
setWalkTypeInstanceAssociations(true) before exporting), but currently it 
does xport the topics (as there is no way for it to tell if the topics are 
referenced elsewhere in the topic map). You can prevent this by creating a 
new TopicMapHandler class which filters these topics out specifically (so 
the TopicMapWalker calls your FilterHandler and your FilterHandler passes 
through everything to the TopicMapWriter, except for the three PSI topics). 
Of course, if you do this, you will need to be careful that your topic map 
does not refer to these topics from any other topics or associations in the 
map.

Cheers,

Kal

At 07:25 17/12/2001 +0000, gautham kasinath wrote:

>Hi! All!
>Well I was trying out samples with the TM4J and I create a topic 
>child_topic of type parent_topic. (Parent topic is already created.)
>Now I get the proper instanceOf tags but then there are three new topics 
>created by the TM4J with Subject Identifiers refering to 
>topicmaps.com/#psi-...
>
>I dunno if theres anythig wrong there.. If i do not wish to let the TM4J 
>to choose a SubIdentifier can I do that??
>Regds
>Gautham Kasinath
>
>P.S. I do not know if every type of a topic must nesasarily refer to those 
>three PSIs.
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers

[Tm4j-developers] One doubt

[gautham k. <gka...@re...>]

Hi! All!=0D=0AWell I was trying out samples with the TM4J and I create a to=
pic child_topic of type parent_topic. (Parent topic is already created.)=0D=
=0ANow I get the proper instanceOf tags but then there are three new topics=
 created by the TM4J with Subject Identifiers refering to topicmaps.com/#ps=
i-... =0D=0A=0D=0AI dunno if theres anythig wrong there.. If i do not wish =
to let the TM4J to choose a SubIdentifier can I do that?? =0D=0ARegds=0D=0A=
Gautham Kasinath=0D=0A=0D=0AP.S. I do not know if every type of a topic mus=
t nesasarily refer to those three PSIs. =0A

[Tm4j-developers] ping

[gautham k. <gka...@re...>]

test ping =0A

[Tm4j-developers] Re: [TM4J-users] TM4J project web site & XTM (was RE: new member)

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

Its taken a little while to get round to answering this ...sorry about that!

At 12:32 23/11/2001 +0100, you wrote:
>Hello again!
>
>[Kal]
> > After all, the (IMHO) best servlet container is Tomcat, and thats open
> > source... I would be interested to see how far an XSLT-only implementation
> > could get. I know that at least one consultant has successfully used XSLT
> > as a means of publishing topic maps.
>
>Which company was this?

The company was Cogitech (www.cogx.com) - you can find some more examples 
and some interesting papers on creating and publishing both topic maps and 
RDF using XSLT.

>[Kal]
> > Apart from the ability to swap stylesheets, what other advantages does
> > Cocoon offer ? Can anyone summarize them for us ?
>
>Not that this is anywhere near a decent *summary*, but there's a few things
>I've noticed in Cocoon which don't seem to be implemented as nicely in
>Velocity. Nonetheless I wouldn't say I were an expert at either, mind you.
>
>* Better XSLFO support: wouldn't it be awesome to be able to browse, say,
>the TM4J dev guide, in XHTML, on-line and at the same time have a PDF version
>of same available at one click, all of which is generated from a single XTM
>source tree?
>
>* Nice built-in caching of XSLT output.
>
>* No nitty-gritty special scripting language, just pure Java and XML for
>Markup nerds like me. OK, I admit that last comment wasn't quite useful. :-)

The caching and the use of compiled XSLT "translets" looks quite good. I 
notice that Cocoon 2.0 is now an official release. From what I have read, I 
think it should be possible to develop a "Generator" for Cocoon that 
extracts topic map data (as XTM format XML ?) and passes it on to what ever 
transformer or serializer modules you care to include. This would work 
really nicely for a "dynamic" site - where you are able to run a servlet 
container on the host machine. However, for our Sourceforge site, and for 
countless other "simple" sites, running servlets is not an option - there 
may be some PHP or Perl support and maybe an mSQL database (if you are 
lucky) but for the most part, you are limted to static HTML. For those 
sites, a Velocity based, scripted static transformation might be a better 
way to go.

If there are volunteers to take on the Cocoon 2.0 generator, I think that 
would be a really worthwhile application. Also if anyone cares to volunteer 
for developing a framework for static transformation (using XSLT or 
Velocity or a combination of the two), that would also be really worthwhile.

I think this discussion is rapidly becoming more of a technical / TM4J 
development issue than an issue of website content. I am therefore copying 
the message to tm4j-developers and would ask that all replies get sent to 
that list.

Cheers,

Kal

[Tm4j-developers] new member - soory I had a wrong adress

[BauerT <Ba...@in...>]

Hallo,

 I m the new one.

 My name is Thomas Bauer and I study the same as Florian Haas.
I m interested in Webdesign, XML and topicmaps.
In webdesign I have much experience, but I m a nobody in XML and
topicmaps.
Nevertheless I m very interested in XML, topicmaps and databases.
 I hope to learn a lot in XML and topicmaps in this project.
 It is fascinates me. - That s why I have chosen this project.

 My function in this project is to develope a homepage for the
 TM4J project.
 At first I have to paint me a picture of the project structure.
 Then I can edit the content for the homepage.

 I need your help. - You can tell me - if you want - the things
 you wanna have on this homepage.
 You can also tell me some ideas of the design you want to have.
 Tell me if there are some homepages I should see to get ideas.



 For questions I m gladly availlable,

 I m happy to be on board,

 Thomas Bauer


 ps: I hope to learn a lot in XML and topicmaps besides my webdesign-work


---------------------------------------------------------------------------=
-
Thomas Bauer

Student der Fachhochschule Informationsberufe

=D6denburger Stra=DFe 25
A - 7064 Oslip

0699 / 109 46 321
mailto: tho...@gm...

RE: [Tm4j-developers] TopicMap interface: getTopics() and getAssociations() methods

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

Hi!

| >just out of curiosity: what's the particular reason why the TopicMap
| >interface's getTopics() method returns a Set, while
| getAssociations(), like
| >getObjects() and the other corresponding getXxx() methods of
| other interfaces,
| >returns a generic Collection?
| >
|
| I originally fluctuated between having interfaces return a
| Collection or a Set. In many cases, a Set is more semantically
| correct, but forces issues such as determining equality and (in
| the case of a
| HashSet at least) a valid hashing algorithm for each object type.
| Ideally, all of these interfaces should be consistent. Over time
| I have tended to lean towards Collection rather than Set, with uniqueness
| constraints (if any) described in function documentation...this
| makes a nice, simple, consistent interface for all operations
| which return multi-valued properties.
|
| This is all the long way of saying 'DOH!' - getTopics() should
| probably be changed to return a Collection rather than a set.


Gotcha. :-)

| >I apologize if this has been discussed on this list before; I
| wouldn't know
| >since the GeoCrawler list search engine at SourceForge.net is
| currently not
| >functional. :-|
| >
|
| Its not working for me at the moment either :-(

Although the error message *is* quite cool -- I like filesystems being named
"/bigassraid". :-)

See ya,

-- Florian

Re: [Tm4j-developers] TopicMap interface: getTopics() and getAssociations() methods

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

11/13/01 3:29:59 PM, Florian Haas <f.g...@gm...> wrote:

>Hello,
>
>just out of curiosity: what's the particular reason why the TopicMap
>interface's getTopics() method returns a Set, while getAssociations(), like
>getObjects() and the other corresponding getXxx() methods of other interfaces,
>returns a generic Collection?
>

I originally fluctuated between having interfaces return a Collection or a Set. In many cases, a Set is more semantically correct, but forces issues such as determining equality and (in the case of a 
HashSet at least) a valid hashing algorithm for each object type. Ideally, all of these interfaces should be consistent. Over time I have tended to lean towards Collection rather than Set, with uniqueness 
constraints (if any) described in function documentation...this makes a nice, simple, consistent interface for all operations which return multi-valued properties.

This is all the long way of saying 'DOH!' - getTopics() should probably be changed to return a Collection rather than a set.

>I apologize if this has been discussed on this list before; I wouldn't know
>since the GeoCrawler list search engine at SourceForge.net is currently not
>functional. :-|
>

Its not working for me at the moment either :-(

Cheers,

Kal

[Tm4j-developers] TopicMap interface: getTopics() and getAssociations() methods

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

Hello,

just out of curiosity: what's the particular reason why the TopicMap
interface's getTopics() method returns a Set, while getAssociations(), like
getObjects() and the other corresponding getXxx() methods of other interfaces,
returns a generic Collection?

I apologize if this has been discussed on this list before; I wouldn't know
since the GeoCrawler list search engine at SourceForge.net is currently not
functional. :-|

tia
-- Florian

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [Tm4j-developers] Missing classes in CVS tree?

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

At 15:11 05/11/2001 +0100, Florian Haas wrote:
> > Hi Florian,
> >
> > They should be checked in now. I can see them in the CVS repository....If
> > you still can't find them, let me know.
> >
> > Cheers,
> >
> > Kal
>
>Hi Kal!
>
>Yep, everything's fine now. Aside from that, just out of curiosity: anyone
>got an idea as to what's wrong with the mailing list archives? The GeoCrawler
>message archive says "No Results Found in This Month" for all the TM4J lists.
>This is not a general SourceForge problem; there are other SourceForge
>projects whose list archives seem to work just fine (alexandria, for 
>example)...
>
>-- Florian

I already replied to Florian in a private email, but the secret is that the 
archiver actually runs once a month (presumably on the last/first day of 
each month), so at the beginning of any given month, all the messages from 
the previous month will be found in the archives.

Cheers,

Kal

Re: [Tm4j-developers] Missing classes in CVS tree?

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

> Hi Florian,
> 
> They should be checked in now. I can see them in the CVS repository....If
> you still can't find them, let me know.
> 
> Cheers,
> 
> Kal

Hi Kal!

Yep, everything's fine now. Aside from that, just out of curiosity: anyone
got an idea as to what's wrong with the mailing list archives? The GeoCrawler
message archive says "No Results Found in This Month" for all the TM4J lists.
This is not a general SourceForge problem; there are other SourceForge
projects whose list archives seem to work just fine (alexandria, for example)...

-- Florian

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

[Tm4j-developers] Missing classes in CVS tree?

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

Kal,

either I'm on the wrong track, or perhaps you didn't (yet) commit some of
the new classes to the CVS repository. :-) Anyway, ant output indicates that
it can't find the following classes:

InvalidNotationException
InvalidLocatorException
LocatorDataFactory

Am I doing something wrong or is the source for these classes in fact
missing?

-- Florian

Re: [Tm4j-developers] Locators

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

On Thu, 25 Oct 2001 11:37:00 +0100
Kal Ahmed <ka...@te...> wrote:

> At 12:17 25/10/2001 +0200, Gerd Mueller wrote:
> 
> > > Here is another interface question. Currently the TM4J API treats all
> > > addresses as a single string. e.g. Occurrence.getResourceRef returns a
> > > string, as does Topic.getSubject and Topic.getSubjectIndicators returns a
> > > collection of strings. This was not always the case, and TM4J still has a
> > > Locator interface hanging around in the source code. Having given this 
> > more
> > > though recently in some discussions with other (commercial) topic map
> > > application developers, I have become more convinced of the benefit of a
> > > "Locator" interface. Here are some of the reasons for this:
> > >
> > > 1) Locators can actually have both an address and a notation. This would
> > > enable support for locators which are not ordinary URIs. e.g. HyTime
> > > locators or proprietary mechanisms for addressing multimedia streams
> > >
> > > 2) There are certain methods which would be generally useful in a Locator
> > > interface. e.g. overriding equals() to handle issues such as
> > > case-insensitivity in domain names in URLs; also the ability to be able to
> > > resolve one Locator relative to another.
> > >
> > > 3) Enables derived classes to carry more internal information which may be
> > > required by certain addressing and / or locator resolution mechanisms.
> > >
> > > So I am proposing that all interfaces where a String is currently used to
> > > supply or return a resource address should be altered to take/return a
> > > Locator instead. Also I think that it would be worthwhile looking at
> > > developing a URLLocator subclass with equals() and resolve() methods. I
> > > think this would be a really nice additional feature to have in the 
> > TM4J API.
> > >
> > > Comments ?
> >
> >Only that one: If there are various implementations of Locator, how
> >do you want to decide which one do you have to use when loading
> >and building a topicmap from an XTM file ? Should this be pattern
> >based, e.g. this reference 'looks like' an URL so I use URLLocator,
> >that 'looks like' HyTime so I use HyTimeLocator ?
> 
> Identifying the form of the Locator is the reason for including the 
> notation property. I was thinking that a LocatorResolverManager would be 
> required. This would delegate to LocatorResolvers based on the notation 
> property of the Locator. The LocatorResolver objects could then further 
> delegate (e.g. a URINotationResolver might delegate to an HTTPResolver or 
> an FTPResolver depending upon the scheme of the locator address.

Okay, sounds good.

Best Regards,
Gerd

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

Re: [Tm4j-developers] Locators

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

At 12:17 25/10/2001 +0200, Gerd Mueller wrote:

> > Here is another interface question. Currently the TM4J API treats all
> > addresses as a single string. e.g. Occurrence.getResourceRef returns a
> > string, as does Topic.getSubject and Topic.getSubjectIndicators returns a
> > collection of strings. This was not always the case, and TM4J still has a
> > Locator interface hanging around in the source code. Having given this 
> more
> > though recently in some discussions with other (commercial) topic map
> > application developers, I have become more convinced of the benefit of a
> > "Locator" interface. Here are some of the reasons for this:
> >
> > 1) Locators can actually have both an address and a notation. This would
> > enable support for locators which are not ordinary URIs. e.g. HyTime
> > locators or proprietary mechanisms for addressing multimedia streams
> >
> > 2) There are certain methods which would be generally useful in a Locator
> > interface. e.g. overriding equals() to handle issues such as
> > case-insensitivity in domain names in URLs; also the ability to be able to
> > resolve one Locator relative to another.
> >
> > 3) Enables derived classes to carry more internal information which may be
> > required by certain addressing and / or locator resolution mechanisms.
> >
> > So I am proposing that all interfaces where a String is currently used to
> > supply or return a resource address should be altered to take/return a
> > Locator instead. Also I think that it would be worthwhile looking at
> > developing a URLLocator subclass with equals() and resolve() methods. I
> > think this would be a really nice additional feature to have in the 
> TM4J API.
> >
> > Comments ?
>
>Only that one: If there are various implementations of Locator, how
>do you want to decide which one do you have to use when loading
>and building a topicmap from an XTM file ? Should this be pattern
>based, e.g. this reference 'looks like' an URL so I use URLLocator,
>that 'looks like' HyTime so I use HyTimeLocator ?

Identifying the form of the Locator is the reason for including the 
notation property. I was thinking that a LocatorResolverManager would be 
required. This would delegate to LocatorResolvers based on the notation 
property of the Locator. The LocatorResolver objects could then further 
delegate (e.g. a URINotationResolver might delegate to an HTTPResolver or 
an FTPResolver depending upon the scheme of the locator address.

Cheers,

Kal

Re: [Tm4j-developers] Locators

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

> Here is another interface question. Currently the TM4J API treats all 
> addresses as a single string. e.g. Occurrence.getResourceRef returns a 
> string, as does Topic.getSubject and Topic.getSubjectIndicators returns a 
> collection of strings. This was not always the case, and TM4J still has a 
> Locator interface hanging around in the source code. Having given this more 
> though recently in some discussions with other (commercial) topic map 
> application developers, I have become more convinced of the benefit of a 
> "Locator" interface. Here are some of the reasons for this:
> 
> 1) Locators can actually have both an address and a notation. This would 
> enable support for locators which are not ordinary URIs. e.g. HyTime 
> locators or proprietary mechanisms for addressing multimedia streams
> 
> 2) There are certain methods which would be generally useful in a Locator 
> interface. e.g. overriding equals() to handle issues such as 
> case-insensitivity in domain names in URLs; also the ability to be able to 
> resolve one Locator relative to another.
> 
> 3) Enables derived classes to carry more internal information which may be 
> required by certain addressing and / or locator resolution mechanisms.
> 
> So I am proposing that all interfaces where a String is currently used to 
> supply or return a resource address should be altered to take/return a 
> Locator instead. Also I think that it would be worthwhile looking at 
> developing a URLLocator subclass with equals() and resolve() methods. I 
> think this would be a really nice additional feature to have in the TM4J API.
> 
> Comments ?

Only that one: If there are various implementations of Locator, how 
do you want to decide which one do you have to use when loading
and building a topicmap from an XTM file ? Should this be pattern
based, e.g. this reference 'looks like' an URL so I use URLLocator,
that 'looks like' HyTime so I use HyTimeLocator ?

Best Regards,
Gerd

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

[Tm4j-developers] Locators

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

Hi all,

Here is another interface question. Currently the TM4J API treats all 
addresses as a single string. e.g. Occurrence.getResourceRef returns a 
string, as does Topic.getSubject and Topic.getSubjectIndicators returns a 
collection of strings. This was not always the case, and TM4J still has a 
Locator interface hanging around in the source code. Having given this more 
though recently in some discussions with other (commercial) topic map 
application developers, I have become more convinced of the benefit of a 
"Locator" interface. Here are some of the reasons for this:

1) Locators can actually have both an address and a notation. This would 
enable support for locators which are not ordinary URIs. e.g. HyTime 
locators or proprietary mechanisms for addressing multimedia streams

2) There are certain methods which would be generally useful in a Locator 
interface. e.g. overriding equals() to handle issues such as 
case-insensitivity in domain names in URLs; also the ability to be able to 
resolve one Locator relative to another.

3) Enables derived classes to carry more internal information which may be 
required by certain addressing and / or locator resolution mechanisms.

So I am proposing that all interfaces where a String is currently used to 
supply or return a resource address should be altered to take/return a 
Locator instead. Also I think that it would be worthwhile looking at 
developing a URLLocator subclass with equals() and resolve() methods. I 
think this would be a really nice additional feature to have in the TM4J API.

Comments ?

Cheers,

Kal

Re: [Tm4j-developers] Interface changes

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

At 09:38 25/10/2001 +0200, Gerd Mueller wrote:
> > 2) Added the VariantContainer interface. This is the interface for an
> > object which contains a list of child Variants. It is a subclass of
> > ScopedObject and a superclass of both Variant and BaseName. It provides 
> the
> > operations getVariants(), setVariants() and addVariant(). Also, Variant
> > will return a Variant Container from its getParent() method.
>
>Where is this interface used ? To model names of topics ?

Essentially, yes. The issue that this interface addresses is that Variants 
can be nested inside other Variants. This means that a Variant might be a 
child of either a BaseName or a Variant. So two things need to happen:

1) Both BaseName and Variant must have methods to add/remove/update the 
list of child Variants
2) The Variant.getParent() method might return either a Variant or a BaseName

Adding this interface encapsulates the common functionality of (1), and 
enables getParent() to return something slightly more type-safe than 
TopicMapObject.

Cheers,

Kal

Re: [Tm4j-developers] Interface changes

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

Hi,

> I'm working on one or two interface changes in TM4J which I would like to 
> run past you guys. If anyone has objections or suggestions for improvements 
> I would be happy to hear them.
> 
> 1) Implemented getParent() in all of the interfaces where it makes sense 
> to. It should now be possible to traverse from a topic map object through 
> its containers up to the TopicMap.

+1

> 2) Added the VariantContainer interface. This is the interface for an 
> object which contains a list of child Variants. It is a subclass of 
> ScopedObject and a superclass of both Variant and BaseName. It provides the 
> operations getVariants(), setVariants() and addVariant(). Also, Variant 
> will return a Variant Container from its getParent() method.
 
Where is this interface used ? To model names of topics ?

> 3) Deprecated get/setName() on Occurrence - these functions were added a 
> long time ago when there was a proposal to add a BaseName to occurrence in 
> XTM. That never happened so this property has no way of being serialised 
> correctly (without going into reification).

+1

> 4) Removed NamedObject interface. Now that only Topic is a container for 
> BaseNames, NamedObject is redundant.

+1

> That's about it for changes that I have made.
> 
> There is also the question of whether  TopicMapObject should have a 
> getTopicMap() method - what do you think about this ? This could be 
> implemented using getParent() - thus avoiding the need to create and 
> maintain another pointer in the TopicMapObjectImpl class, and it is 
> probably a pretty useful operation...

+1, It would complete the navigation axises through a topicmap.

Best Regards,
Gerd

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

[Tm4j-developers] Interface changes

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

Hi,

I'm working on one or two interface changes in TM4J which I would like to 
run past you guys. If anyone has objections or suggestions for improvements 
I would be happy to hear them.

1) Implemented getParent() in all of the interfaces where it makes sense 
to. It should now be possible to traverse from a topic map object through 
its containers up to the TopicMap.

2) Added the VariantContainer interface. This is the interface for an 
object which contains a list of child Variants. It is a subclass of 
ScopedObject and a superclass of both Variant and BaseName. It provides the 
operations getVariants(), setVariants() and addVariant(). Also, Variant 
will return a Variant Container from its getParent() method.

3) Deprecated get/setName() on Occurrence - these functions were added a 
long time ago when there was a proposal to add a BaseName to occurrence in 
XTM. That never happened so this property has no way of being serialised 
correctly (without going into reification).

4) Removed NamedObject interface. Now that only Topic is a container for 
BaseNames, NamedObject is redundant.

That's about it for changes that I have made.

There is also the question of whether  TopicMapObject should have a 
getTopicMap() method - what do you think about this ? This could be 
implemented using getParent() - thus avoiding the need to create and 
maintain another pointer in the TopicMapObjectImpl class, and it is 
probably a pretty useful operation...

Cheers,

Kal

Re: [Tm4j-developers] Deep/shallow copy behaviour

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

At 08:17 02/10/2001 +0200, Norbert Hartl wrote:


>Kal Ahmed wrote:
>
>>Hi,
>>I'm starting to look at implementing the copy() functions and I have a 
>>few issues that might be worth discussing:
>>Firstly, when making a copy, it is very easy to end up duplicating both 
>>ID values and resourceID values - naturally, this is not allowed and will 
>>cause exceptions to be thrown. I propose that we solve this by allowing 
>>the user to specify a prefix and a suffix to be applied to the ID and 
>>resourceID properties so that the if the source object has id 'foo', the 
>>copied object's id will be prefix + "foo" + suffix and if the source 
>>object has resource id "http://www.some.domain/some/path#footopic", then 
>>the copied object's resourceID will be 
>>"http://www.some.domain/some/path#footopic" + suffix. I'm not including 
>>the prefix in the resourceID property because it would require parsing 
>>the resourceID URL - which I would like to avoid.
>
>Does it make sense to copy an Object into its own TopicMap? First the IDs
>will clash. If we change IDs then the topic will be merged immediately,
>won't it? Otherwise if we copy from one map to another the id problem
>isn't there, right? Just to get an understanding from it.
>Altering strings with pre/suffix it is hard to make sure that the operation
>is reversible.

It may make sense to copy objects other than Topics - e.g. duplicating an 
occurrence to then add it to a different Topic. It may also make sense to 
duplicate Topics which are 'anonymous' - but I admit that it would probably 
be a little unusual. Perhaps preventing the duplication of objects into the 
same topic map would make sense.

>Is it right to think that every copy() operation should be reversible like
>this:
>
>         Topic src; // created from f1
>         TopicMapFactory f1;
>         TopicMapFactory f2;
>
>         // _before_
>         f1.copy(f2.copy(src));
>         // The TopicMap from f1 should be the same as _before_

That is an interesting requirement - it would mean that the duplication 
process 'provably' produces a copy, but I'm not sure that it is necessary 
though.


>>Secondly, we need to define exactly what constitutes a deep and a shallow 
>>copy. Here is my proposal (use a fixed-pitch font to see the table)
>
>As long as I understand it the table looks good.
>
>Do we then need a resolve() action. I see that in such thing like a topicmap
>
>it is hard to prevent copying to whole topicmap with a single copy() 
>operation.
>So when creating a second map from copying operations we will have a new map
>with new objects referencing a lot of objects from the sourcemap. (e.g. 
>the types
>of a topic). When it comes to save the new map what will happen? Will this 
>create
>empty topics in the second map for those which are referenced from the 
>sourcemap?

Unless I have missed something out of the table, I believe that the 
proposed shallow and deep copies should never
copy a reference to anything other than a String object. So a resolve() 
operation would only duplicate Strings. Now that I think about it, I'm not 
sure that copying String references between topic maps is wise. They would 
almost certainly be deep copied when the topic map is stored to its 
back-end, so perhaps it would be better to always deep-copy strings.

>Or do we have a resolve() action which cleans up a map (copying the needed 
>objects
>into the map from references).

Unless we choose to allow the copy() operations to create references to 
TopicMapObjects in the source TopicMap, rather than creating a new object 
and copying some/all of its properties, a resolve() operation is probably 
not necessary in this context.


>Which purpose should copy() serve?

The original purpose which motivated the creation of the copy() 
functionality was to duplicate objects so that they could be used as the 
model in an MVC edit dialog without passing the changes through to the 
source topic map until they are finally committed. I think that in this 
instance you would typically create a deep copy of the object to be 
modified in a 'scratch' in-memory topic map. You could then pass the 
updates back into the source topic map either by removing the source object 
and adding a deep copy of the edited object or by doing a 
property-by-property comparison and update.

Another purpose might be to 'resolve' external topic references by copying 
the referenced topic map objects into the topic map making the references 
and updating those references (here I am thinking of resolving topics by 
determining if they have a subjectIndicator which points to a <topic> 
element in another topic map - then you may want to parse that topic map 
and copy the referenced topic).

What other use cases do we have in mind for copy() ?

Cheers,

Kal

[Tm4j-developers] Deep/shallow copy behaviour

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

Hi,

I'm starting to look at implementing the copy() functions and I have a few 
issues that might be worth discussing:

Firstly, when making a copy, it is very easy to end up duplicating both ID 
values and resourceID values - naturally, this is not allowed and will 
cause exceptions to be thrown. I propose that we solve this by allowing the 
user to specify a prefix and a suffix to be applied to the ID and 
resourceID properties so that the if the source object has id 'foo', the 
copied object's id will be prefix + "foo" + suffix and if the source object 
has resource id "http://www.some.domain/some/path#footopic", then the 
copied object's resourceID will be 
"http://www.some.domain/some/path#footopic" + suffix. I'm not including the 
prefix in the resourceID property because it would require parsing the 
resourceID URL - which I would like to avoid.

Secondly, we need to define exactly what constitutes a deep and a shallow 
copy. Here is my proposal (use a fixed-pitch font to see the table)

Object          Shallow Copy                    Deep Copy
---------------------------------------------------------------------------------
TopicMap                Populate with a shallow         Populate with a 
deep copy of the
                         copy of the topics and          topics and 
associations in src
                         associations in src

Topic           A new Topic which will merge    A new Topic with a deep 
copy of all
                         with the source Topic.          BaseName and 
Occurrences.
                         The duplicate will not          All types are 
shallow copied (they will
                         have any copied base names,     merge with the 
deep copy of the same
                         or occurrences and will         topic if it 
exists/is added to the
                         not be a part of any            destination topic map)
                         associations that the source    The rolesPlayed 
property is not copied.
                         object is a part of.

Association     A new Association with          A new Association with 
deep-copied members
                         shallow copied Members

Member          A new Member object which       A new Member object which 
contains a deep
                         contains a shallow copy         copy of the topics 
in its rolePlayers
                         of the topics in its            and roleSpec 
properties
                         rolePlayers and
                         roleSpec properties.

BaseName                A new BaseName object           A new BaseName 
object whose string property
                         whose string property is        is a duplicate of 
the string property of the
                         a reference to the string       source object and 
whose child variants are deep
                         property of the source          copies of the 
child variants of the source object.
                         object and whose child
                         variants are shallow copies
                         of the child variants of the
                         source object.

Variant         A new Variant object with       A new Variant object with 
deep-copied
                         shallow copied topics in        topics in its 
parameters property and
                         its parameters property         deep-copied child 
variants and variantNames
                         and with shallow-copied
                         child Variants and child
                         VariantNames.

VariantName     A new VariantName object        A new VariantName object 
with resourceData
                         with resourceData and           and resourceRef 
properties which are
                         resourceRef properties          duplicates of the 
string values in the source
                         which reference the string      object.
                         value in the source object.

Occurrence              A new Occurrence object         A new Occurrence 
object with a deep-copied
                         with a shallow-copied type      type and with 
resourceData and resourceRef
                         and with resourceData and       properties which 
are duplicates of the
                         resourceRef properties          string value in 
the source object.
                         which reference the string
                         value in the source object.

Scope           A new Scope object whose        A new Scope object whose 
themes property
                         themes property is a            is a collection of 
deep copies of the topics
                         collection of shallow copies    is the themes 
property of the source object
                         of the topics in the themes
                         property of the source object

ScopedObject    A new ScopedObject whose        A new ScopedObject whose 
scope property
                         scope property is a shallow     is a deep copy of 
the source object's scope.
                         copy of the source object's
                         scope.
The most crucial part of this is the treatment of a shallow copy of a 
topic. By only producing a topic which will merge with the source topic, we 
keep the amount of object copying to a minimum. I am in two minds about 
this - I think that this definition of a shallow copy is elegant as it 
ensures that a shallow copy will never spill out to copy the whole topic 
map but it has the disadvantage of providing very little copying. An 
alternate definition would be to shallow copy all of the name and 
occurrence characteristics of the source Topic, shallow copy the types and 
not copy the rolesPlayed at all.

Any comments ?

Cheers,

Kal
                 

RE: [Tm4j-developers] Source tree changes

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

Hello all,

[Kal]
| 	$CVSROOT/src/com/techquila/topicmap/dom - Florian, I didn't
| know if you
| were in the middle of things. If you have checked everything in, then
| either move the package yourself or let me know and I'll do it.

I wasn't in the middle of anything, actually. I checked everything in before
Friday 1700 UTC and froze my development until after the actual name change.
I took care of the org.tm4j.topicmap.dom package myself; if there were any
hiccups in the check-in process, please let me know. Everything does compile
file on my machine, though. :-)

Take care

-- Florian

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

tmHi,


> 
> Thats the reason why I prefer (3). copy() is also some kind of creation method 
> and should be a method of the factory. Also if we use approach (2) we would need
> to pass a factory to the copy() method of the TopicMapObject. This looks somehow
> odd to me.
> 
No, this is a misunderstanding. My idea proposal started from a ownerMap reference

in TopicMapObject. Via this one you can get the according factory from any
TopicMapObject via this.getOwnerMap().getFactory(). So, there is no need 
to have
factory as parameter at all. So it's very easy to have a static method 
while every
objects carries his factory with it. I mentioned that with this approach
the location of the implementation of such a copy method is arbitrary.
The factory is hidden inside the objects.
Our both approaches aren't that different. Its just a matter what object 
references
to carry to methods of other objects.

Example GUI:

In this situation we have a component which is able to modify e.g. an 
topic object.
In order to be able to cancel any modification the component should work 
on a copy
object instead of the original topic.
With your approach code will look like this:

	Topic src, tmpTopic;
	Component topicComp;
	TopicMapFactory copyFactory;

	tmpTopic = copyFactory.copy(src);
	topicComp.setFactory(copyFactory); // you'll need this because comp may 
create new
	topicComp.setTopic(tmpCopy);

Mine would like this:

	Topic src, tmpTopic;
	Component topicComp;
	TopicMapFactory copyFactory;

	tmpTopic = copyFactory.createTopic();
	tmpTopic.copy(src);
	topicComp.setTopic(tmpCopy);

The main difference of those both is that in your approach we don't need a reference

inside TopicMapObject but we have to carry the Factory ourselfs around.


I wrote this only to make clear my intentions. This doesn't cancel my 
agreement to your
solution.

have a nice day,

NoB

[Tm4j-developers] Source tree changes

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

I have now moved the directory $CVSROOT/src/com/techquila/topicmap and 
almost all of its subdirectories to $CVSROOT/src/org/tm4j/topicmap. I have 
also updated the source code to compile correctly (at least it does on my 
machine ;-)

I have *not* moved the following:

	$CVSROOT/src/com/techquila/topicmap/dom - Florian, I didn't know if you 
were in the middle of things. If you have checked everything in, then 
either move the package yourself or let me know and I'll do it.

	$CVSROOT/src/com/techquila/topicmap/test - Norbert, do you want these test 
files to be moved or would you prefer to simply check in new source files ?

I have also updated the TMNav code to compile correctly but I have not 
moved it into the org.tm4j hierarchy. My reasoning is that we can reuse the 
name TMNav for something a little more robust ....

Cheers,

Kal

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

At 17:32 28/09/2001 +0200, Gerd Mueller wrote:

> > >> - which interfaces would be changed?
> > >> - where is the copy implementation?
> > >
> > >
> > > OK. This is where I think we are. There are thre approaches to copying
> > > currenlty on the table
> > >
> > > 1) The back-end independent copier object method - as represented by
> > > TopicMapCopier
> > > 2) Norbert's suggestion that copy() functions be implemented as part of
> > > the interfaces of TopicMapObject and derived classes
> > > 3) Gerd's suggestion that copy() functions be implemented as part of the
> > > interface of TopicMapFactory
> > >
> >
> > Just to stress this point enough. Every solution has to be
> > backend-independent.
> > It is (without any doubt) a good idea to prefer (3). I like the idea 
> because
> > inside a copy method the create..() methods are needed. And the Factory
> > is the
> > place where they reside.
>
>Thats the reason why I prefer (3). copy() is also some kind of creation 
>method
>and should be a method of the factory. Also if we use approach (2) we 
>would need
>to pass a factory to the copy() method of the TopicMapObject. This looks 
>somehow
>odd to me.

Well I prefer (3) as well. So it looks like we are agreed to try this way 
unless Florian has any objections.

I have a little free time now so I might try and look at this today. 
However, I'll move the existing source code over to org.tm4j before 
starting work on this.

Cheers,

Kal

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

> >> - which interfaces would be changed?
> >> - where is the copy implementation?
> > 
> > 
> > OK. This is where I think we are. There are thre approaches to copying 
> > currenlty on the table
> > 
> > 1) The back-end independent copier object method - as represented by 
> > TopicMapCopier
> > 2) Norbert's suggestion that copy() functions be implemented as part of 
> > the interfaces of TopicMapObject and derived classes
> > 3) Gerd's suggestion that copy() functions be implemented as part of the 
> > interface of TopicMapFactory
> > 
> 
> Just to stress this point enough. Every solution has to be 
> backend-independent.
> It is (without any doubt) a good idea to prefer (3). I like the idea because
> inside a copy method the create..() methods are needed. And the Factory 
> is the
> place where they reside.

Thats the reason why I prefer (3). copy() is also some kind of creation method 
and should be a method of the factory. Also if we use approach (2) we would need
to pass a factory to the copy() method of the TopicMapObject. This looks somehow
odd to me.

> Should we put the copy implementation in the TopicMapFactory. This will 
> change
> TopicMapFactory to an abstract class. If we don't like this idea we should
> have a further look at (1).

bye,
gerd

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