[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 ?

If this is OK, I'll implement this policy for the next release of TM4J -
most of the changes are localised in the XTMBuilder and XTMWriter classes.

Cheers,

Kal

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