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

Murray Altheim m.altheim@open.ac.uk
Mon, 26 May 2003 02:47:35 +0100


Lars Marius Garshol wrote:
 > * Lars Marius Garshol
 > |
 > | Not really. You can just give the full URI directly in the XTM
 > | document that you distribute. That solves the problem.
 >
 > * Murray Altheim
 > |
 > | No, if I download (for example) the language.xtm document from the
 > | XTM 1.0 website directory, [...]
 >
 > The problem you point out with language.xtm is of course correct, but
 > that does not contradict what I wrote. I wrote "just give the full URI
 > directly in the XTM document that you distribute", and language.xtm
 > does not do this, so we are not talking about the same thing.

Lars Marius, I've noticed that you are exceedingly exacting in your
communication, but you sometimes completely fail to communicate. I could
care less about the disagreement, about what you said or what I said.
If you aren't talking about the same subject as I am, then start a
new thread.

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.

 > | In fact, once downloaded, if we can't use xml:base to tell the
 > | processor that the canonical location of the document, it's
 > | canonical base URI, is at topicmaps.org, then there's no way to
 > | distribute and use local copies of PSI documents.
 >
 > Yes, there is. See

No, there isn't.

 >   <URL: http://psi.oasis-open.org/iso/639/639-core.xtm >
 >
 > which does it as follows:
 >
 >   <topic id="language">
 >     <subjectIdentity>
 >       <subjectIndicatorRef xlink:href="http://psi.oasis-open.org/iso/639/#language"/>
 >     </subjectIdentity>
 >     <baseName>
 >       <scope><subjectIndicatorRef xlink:href="http://psi.oasis-open.org/iso/639/#eng"/></scope>
 >       <baseNameString>Language</baseNameString>
 >     </baseName>
 >     <baseName>
 >       <scope><subjectIndicatorRef xlink:href="http://psi.oasis-open.org/iso/639/#fra"/></scope>
 >       <baseNameString>Langue</baseNameString>
 >     </baseName>
 >   </topic>
 >
 > 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.

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. 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...". I think Guy
was pretty clear that if XML Base doesn't give us what we need, it
doesn't give us what we need. Full stop.

 > | I admit that would be silly, and inappropriate. If your application
 > | has already parsed an XML document (which is where you encountered
 > | the fragment ID in the first place) and are resolving internal
 > | fragment IDs within that document, as in your example,
 > |
 > |  >   <xxxRef xlink:href="#foo"/>
 > |
 > | You simply use the resource you're already in. If RFC 2396 suggests
 > | that you'd want to download a different resource when resolving
 > | local references within a document, that doesn't make any sense.
 >
 > That is precisely what RFC 2396 does not say. It says that this URI,
 > when absolutized, becomes
 >
 >   document-uri#foo
 >
 > which is of course what we've been discussing all along. If it said
 > that the URI absolutized to
 >
 >   base-uri#foo
 >
 > we would have the situation you describe: processors wanting to
 > resolve the URI would find themselves downloading the canonical
 > document from the canonical location, which what we wanted to avoid.
 >
 > So the rationale for the decision you don't like in RFC 2396 and XML
 > Base (bare fragment references (like "#foo") resolve relative to the
 > document URI rather than the base URI) is precisely to enable the
 > behaviour that you here say you want.

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.)

 > In short, I'm a bit confused about why you are unhappy about this.
 > Not that it really matters whether any of us are happy or unhappy
 > about this: RFC 2396 says what it says, and we, like XML Base, must
 > follow it.

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.

 > What we *could* do is try to come up with some workaround if this
 > causes problems for XTM users. But as far as I can tell it does not.

No, I'd prefer that XML Base do the job that I (and I'm quite certain
the HTML WG and probably a whole lot of others too) thought we got when
we got that nice little xml:base attribute that was supposed to
provide a canonical location for the document. We don't need any more
workarounds, we need the specs to get it right in the first place. A
whole lot of people (not just me) are likely misinterpreting this
spec because it was expected that it provided the same thing as HTML's
<base>. So if xml:base doesn't solve the problem, maybe the W3C should
create something called 'xhtml:base' that does what many of us wanted...

If I sound a bit frustrated it's perhaps that this crap should have
been resolved back in 1995 or 1996. I can't believe we're still
discussing this, and that XML Base doesn't do what we all need it to do.
I could give a hoot about RFC this or that. If there's a problem with
some RFC, rewrite it, as has been done with every other conflict that
has arisen. This isn't some immutable religious dogma. We need the
functionality, it was provided as a requirement from the HTML WG back
in 1999(!) [XLINKREQ], discussed ad nauseum within the W3C (explicitly
discussing the HTML base issue probably hundreds of messages), and now
in 2003 I find that whole thing is screwed up. Criminy.

Murray

[XLINKREQ] http://www.w3.org/TR/NOTE-xlink-req/#design (#3)
...........................................................................
Murray Altheim                         http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK                    .

    "We can now hypothesise with some confidence that those apparently
     happy, calm Buddhist souls one regularly comes across in places
     such as Dharamsala, India, really are happy," said Professor Owen
     Flanagan, of Duke University in North Carolina. -- BBC News
     http://news.bbc.co.uk/1/hi/health/3047291.stm