Possible Future Developments


Shift from {@link Int.ecb.gesmescb.util.TimePeriod} to {@link Int.ecb.gesmescb.time}

The better understood and better documented package time should over time replace the old class util.TimePeriod. That package is also more in the spirit of Java since it is based on interfaces.

The changes in this area will be implemented gradually and should not be very noticeable to the outside.

Frontend with named components

All components which pass around GESMESCBObjects will implement a dedicated interface. All will have a name and be connected according to instructions in the configuration file. Very flexible.

Basic classes become interfaces

To allow users of the library to use own implementations of the classes like {@link Int.ecb.gesmescb.TimeSeries}, it could be discussed to replace these classes by equivalent interfaces. Of course the reference implementations would remain accessible, though possibly in a different package than {@link Int.ecb.gesmescb}.

Implement a unified error reporting pattern

Error reporting is a known weakness. The approach to use the logging mechanism for that is disputable. Also we may want to generate a set of error objects and error object formatters. This should make it easier to report errors in a more uniform way, perhaps even using multiple languages and localization.

Renaming classes/operations

Adapt to upgraded Java APIs

Java 1.4 contains packages for logging and preferences. When time has come, these should be used in place of {@link Int.ecb.logging} and {@link Int.ecb.prefs}, respectively.

Add a method {@link Int.ecb.gesmescb.event.GESMESCBReader}.setSource(String)

This method should on the one hand allow re-use of GESMESCBReaders and on the other hand give the top level {@link Int.ecb.gesmescb.application.Loader} a uniform possibility to govern the sources.

A similar method {@link Int.ecb.gesmescb.event.GESMESCBWriter}.setDestination(String) could also be thought of.

Select {@link Int.ecb.gesmescb.event.GESMESCBWriter}s using {@link java.lang.reflect reflection}

This is similar to the choice of a reader using the {@link Int.ecb.gesmescb.application.Loader#prefs Loader preference} dataReaderClass. A proposal would be to define properties dataWriterClass.1, dataWriterClass.2, and so on. The advantage is that if a user has written an own GESMESCBWriter, the Loader application need not be recompiled to support it. This has been implemented in the {@link Int.ecb.gesmescb.application.BatchTextUI}!

Store source location in {@link Int.ecb.gesmescb.GESMESCBObject}s

At present, the {@link Int.ecb.gesmescb.semanticchecker.SemanticChecker}, when reporting errors, cannot indicate the Gesmes/TS line and pseudocolumn where the error occurred. This information is available to the {@link Int.ecb.gesmescb.edifact.EDIFACTReader} but is not transported in GESMESCBObjects. This makes it difficult in some cases for a user to find the location of the error in the source file. Typically, a {@link Int.ecb.gesmescb.TimeSeries} key is sufficient though not convenient for an experienced user of Gesmes/TS-EDIFACT to search in the EDIFACT source. However, locating errors in more complex data formats like Gesmes/TS-XML or a database may require additional information.

Therefore, each GESMESCBObject should carry a reference to its origin. The reference would probably use a placeholder-interface with implementations for each type of input data and maybe also different for different GESMESCBObject classes (because e.g. a {@link Int.ecb.gesmescb.MessageBegin} takes its information from various positions in the Gesmes/TS-EDIFACT source.

Make {@link Int.ecb.gesmescb.InterchangeEnd} and {@link Int.ecb.gesmescb.MessageEnd} implicit

These objects are a relict from the time when the {@link Int.ecb.gesmescb.event.GESMESCBWriter} did not have a {@link Int.ecb.gesmescb.event.GESMESCBWriter#close()} method. Nowadays, a call to this method conveys the information that the end has been reached.

Abstract {@link Int.ecb.gesmescb.metabase.Metabase}

An abstract class Metabase with a factory method to access the singleton will allow retrieval of structural definitions from other than pre-loaded storage structures in memory.

It also goes well with the idea to configure the structural definitions source file/database in the config file rather than on the command line. Even loading from an application server via a URL is thinkable.

In connection with the new layout for the Metabase, the {@link Int.ecb.gesmescb.event.ThreadPump} will no longer need to flush the queue after each message.

The current situation where the metabase acts as a normal listener is not compatible with multiple threads, because the metabase relies on internal status (particularly the current maintenance agency) which must not be changed between handle calls.

Use {@link Int.ecb.gesmescb.sieve.GESMESCBEventSieve}s without filter

The current sieve can be configured to use one {@link Int.ecb.gesmescb.sieve.GESMESCBObjectFilter} to distinguish expected from unexpected objects. It acts as a handle for such a filter.

Unfortunately, it is not possible to configure more than one filter with a sieve. Also, the filter API is structurally very similar to the general event handler API defined in {@link Int.ecb.gesmescb.event.GESMESCBEventListener} and its sub-interfaces.

Therefore, it may simplify the overall API to use only the handler API and drop the filter. To overcome the limitation as to the number of filters, a configuration method similar to the {@link Int.ecb.gesmescb.application.BatchTextUI}'s writer configuration may be used.

The same approach could simplify the (package internal) API in the {@link Int.ecb.gesmescb.semanticchecker} by distributing various checks to different checker classes forming a sequence.