RE: [topicmaps-comment] referring to a topic from outside a TM

["Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com>]

Title: RE: [topicmaps-comment] referring to a topic from outside a TM

> [Thomas B. Passin]
> I don't see that there has to be a fundamental difference
> between fragment
> identifiers and query  strings in practice.  If I can do a GET
> http://bigmap.com/thetopicmap#tt-storm, it amounts to an
> index into bigmap's  topic map. 

There is a very practical problem:

When you send an URIreference contining a fragment identifyer, and that URI points to some dynamic service (like a Java Servlet), most probably this service will have no chance to get hold on the fragment id.

I tried this today using the JSDK2.0 Java Package (HttpServletRequest and HttpUtils) with TomCat, and with an Apache/JServe combi. There is no way to access the fragment identifyer from within the servlet.

Again: A bug or a feature?

It may be a feature. www.ietf.org/rfc/rfc2396.txt clearly states that the fragment identifyer is not part of the URI, but of an URI reference:

<<< A URI reference may be absolute or relative,
   and may have additional information attached in the form of a
   fragment identifier.  However, "the URI" that results from such a
   reference includes only the absolute URI after the fragment
   identifier (if any) is removed and after any relative URI is resolved
   to its absolute form.
>>>, or:
<<<  URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] >>>

The meaning of the fragment identifyer is bound to certain media (mime-) types. XPointer defines that for the XML-related mime-types.

But there is *no* defined semantic for dynamic services like Java Servlets. That is why the servlet engine ignores it.

The same RFC contains the concept of *queries*, which are commonly used and designed for *general* use:

<<<The query component is a string of information to be interpreted by
   the resource. >>>
A query is considered to be part of the URI(<scheme>://<authority><path>?<query>) itself, so it can be accessed by the servlet.

I may like this or not. The result is: #fragment cannot be used by database implementations (I am not considering possible "hacks" here - a standard cannot be based on hacks)

> It's not defined what should be returned from
> that request, but
> presumably it would be a topic element if tt-storm were the
> id of a topic.
> Note that HTML browsers don't behave that way, they get the
> whole document
> and scroll to the anchor. 
[...]
> If I do a GET
> http://bigmap.com/thetopicmap?gettopic=tt-storm, I ask the
> server to do something that is up to the server, but
> presumably will be
> related to the topic id in some way.

I think that IE6 really does not support Xpointer. IE does not care for XML *validity* but is happy with just *well-formed* docs. So it will not care about the data types (including ID). IE knows to look for <a name="xyz"> in html-mime types. But how to detect the mime types mentioned in the XPointer rec? Maybe someone knows more about this. 

For HTML, <a name="xyz"> marks the start position of the required information, but there is no defined end position than the end of the document. The only one who takes care that <a name="xyz"> is included exactly before the beginning of the topic (ps) with ID xyz is the editor of the document.

For Xpointer, the application has to look for *any* tag with ID="xyz" (XML validating should have asured that this ID is unique, but it can be in any tag. So this may find:

<joking id="xyz"> did you expect a topic in this place? HaHaHa! </joking>. The only one to take care for this is the editor of the document.

For queries like "?id=xyz" the query does not specify what has to be returned. The server can do anything. The only one responsible for this is the editor of the database service behind.

What's the difference? All 3 cases depend on conventions.

But all 3 case use valid URIs (hmm, to be more precise: URI-references).

[...]
> The thing is to get what you want without too many network
> calls and too
> many requests on the server.  Everyone can see how to walk a
> topic map bit
> by bit, but how to get what you need to put that topic or
> association in
> context so that it can be interpreted, preferably in one
> chunk and without
> too big a load on a server, is harder.  That's what I have
> been posting
> about.

Only using the request (i.e. query method) gives us the freedom to specify anything about this. I personally prefer "many requests to the server", since I am used to fast internet connections. In a "normal" working situation I do not download documents, but I consult them on line. If you need to download a copy for some reasons, the request should support to return the complete topicMap in one document. You can supply several options about "chunking".

> For example, if you get an association, should you also get
> the topics that
> play role in that association, or should you just get
> references to them?
> The latter doesn't fit most processing models to date.

I don't understand this. If the reference is a valid URL, it does not make any difference to the processing modell. It is just a question of speed and connectivity, not of the processing model.

> The key point is the agreement or spec about the interpretation of the
> request and the form of the response.  We don't have that
> yet, but it will
> come.

Hopefully.
We should support several "chunking" options (like one-by-one, assoc-with-topics, ....)
I am thinking about proposing a *filter* attribute for  <topicMap> to indicate the kind (and query) of fragment in it.

Thomas Bandholtz
XML Competence Center
SchlumbergerSema
Sema GmbH
Kaltenbornweg 3
D50679 Köln/Cologne
++49 (0)221 8299 264