[topicmapmail] ["Jonathan Marsh" <jmarsh@microsoft.com>] RE: XML Base question

[Lars Marius Garshol]

* Murray Altheim
| 
| What I do care about is the problem I was talking about. I don't
| know if you were talking about it or not. The problem I outlined
| still exists, and the "workaround" you suggest does not solve the
| problem that language.xtm and any other XTM document published as
| part of a PSI set.

If you are saying that there are problems with language.xtm,
country.xtm, and core.xtm as published, I agree. What I don't see is
that there are problems that can't be solved with new PSI sets.
 
* Lars Marius Garshol
|
| The PSIs are given as absolute URIs, which means that when you
| download the XTM file and read it locally you get the same URIs.
 
* Murray Altheim
|
| Adding a subjectIndicatorRef to the above <topic> elements doesn't
| give those PSIs identity with the topic elements they're in, since
| that nice long PSI isn't connected to the XML ID. 

It does connect the two identities, but it does not make them the
same. That's a subtle difference, and I must admit I have no idea why
you think it is important that the XML ID turn into the same URI as
the PSI.

| So if I've downloaded 639-core.xtm and loaded it into my XTM
| processor, resolving the PSI doesn't give me that <topic> element,
| and resolving that <topic>'s ID doesn't give me the PSI, if gives me
| "file:/usr...". 

That is correct. But what is the problem with that? Why is that an
issue?

| Where did we begin to ascertain "relative references" as fragment IDs?
| Relative references (as provided in every previous example) were about
| resolving document references relative to the base URI provided, so
| that images, other links, etc. worked. The fragment ID is *ALWAY* a
| reference within the same document, so if you've downloaded a resource
| that has a bare fragment ID, it *ALWAYS* resolves within the same
| resource. (Unless of course the W3C has messed this one up too.)

That's what we've just agreed, but that has to mean that such
references ignore the base URI. This is a black/white thing, Murray.
Either it ignores the base URI (and then we get the behaviour
described above, which you are unhappy with) or it respects the base
URI (and then references in local copies lead to downloads from the
canonical location, which you are also unhappy with).

In short, I don't see any way to solve this problem that would not
cause us to end up with behaviour you don't like. In my view, the
second problem is a real problem, whereas I have yet to understand
that there is anything wrong with the first behaviour.
 
| Man, you sound like the RFC was god or something. It *could* be
| wrong, eh? The world *could* be messed up, eh? RFC 2396 could be
| wrong -- is this not a possibility? And if it was wrong, it could
| have been fixed.

"Could have been" is the key part of that sentence. The decision was
made, and I don't think it's very likely that it will be changed now.
As far as I can see there is no problem caused by this behaviour, so
there is no need for it to change, either.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >