Re: [Tm4j-developers] Improving development environment for TM4J

[Conal T. <con...@vu...>]

On Mon, 2008-01-28 at 15:21 +0100, Lars Marius Garshol wrote:
> * Kal Ahmed
> >
> > Finally on Locators, the logic behind the Locator structure in the =20
> > original TM4J was that it should be possible to support a wider =20
> > range of locator syntaxes than URI/URL syntax. In practice, URIs (or =20
> > maybe IRIs) have won and the Locator class is probably something of =20
> > an anachronism =E2=80=93 a simple Unicode character sequence (backed up=
 with =20
> > the library functions for parsing and handling those strings as =20
> > URIs) should work for a =E2=80=9Cnew=E2=80=9D topic map engine.
>=20
> A word of caution here: URI processing is quite complex, and in Topic =20
> Maps import it's also performance-critical. Small changes to how URIs =20
> are processed can mean a huge difference in the time needed to load an =20
> XTM file. This may sound strange until you stop to consider just how =20
> many URIs there are in an XTM file.
>=20
> The built-in Java classes for URIs have quite a few issues in this =20
> regard, and so you may want to consider keeping some sort of interface =20
> in front here in order to give yourself latitude to make this efficient.

Personally I've never used Locators of any other type than URI, since
I've been using XTM for input, but I agree with Lars that the API needs
a "Locator" abstraction. I don't think there's anything in the Locator
interface which imposes a heavy memory footprint is there?


--=20
Conal Tuohy
New Zealand Electronic Text Centre
www.nzetc.org