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

[Guy Murphy]

I'm with Murray on this one. I fail to see how any other treatment of
xml:base can be reagrded as either logical or more importantly useful.

Since when did the base designation not indicate where the cannonical
location of the document is for processing?

Such processing is useful (one might argue essential), so that one can
download onto your local system part of a composite document and be assured
that relative links will resolve appropriately to the resources they are
pointing to.

Who decided otherwise and where do I contact them?

Am I missing something fundamental to this argument?

Cheers,
    Guy.

----- Original Message -----
From: "Murray Altheim" <m.altheim@open.ac.uk>
To: "Lars Marius Garshol" <larsga@garshol.priv.no>
Cc: "topicmapmail" <topicmapmail@infoloom.com>; "Jonathan Marsh"
<jmarsh@microsoft.com>
Sent: Friday, May 23, 2003 5:16 PM
Subject: Re: [topicmapmail] ["Jonathan Marsh" <jmarsh@microsoft.com>] RE:
XML Base question


> Lars Marius Garshol wrote:
> > * Murray Altheim
> > |
> > | This really messes up our ability to express PSIs in documents
> > | portably.
> >
> > Not really. You can just give the full URI directly in the XTM
> > document that you distribute. That solves the problem.
>
> No, if I download (for example) the language.xtm document from the
> XTM 1.0 website directory, we can interpret the document either as
> I *thought* XML Base described (which would have agreed with the
> requirement on supporting HTML's base for XHTML as directed by the
> HTML WG), or as has been described recently. Let's pretend this
> document is now on my local system at
file:/usr/local/sgml/xtm/language.xtm
>
> <?xml version="1.0"?>
> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM)
V1.0//EN"
>                            "xtm1.dtd">
> <topicMap id="xtm1.0-psi-language"
>      xmlns="http://www.topicmaps.org/xtm/1.0/"
>      xmlns:xlink="http://www.w3.org/1999/xlink"
>      xml:base="http://www.topicmaps.org/xtm/1.0/">
> ...
>    <topic id="aa">
>      <instanceOf><topicRef xlink:href="#lang-code"/></instanceOf>
>      <baseName><scope><topicRef xlink:href="#alpha2"/></scope>
>        <baseNameString>aa</baseNameString></baseName>
>      <baseName><scope><topicRef xlink:href="#en"/></scope>
>        <baseNameString>Afar</baseNameString></baseName>
>    </topic>
>    <topic id="ab">
>      <instanceOf><topicRef xlink:href="#lang-code"/></instanceOf>
>      <baseName><scope><topicRef xlink:href="#alpha2"/></scope>
>        <baseNameString>ab</baseNameString></baseName>
>      <baseName><scope><topicRef xlink:href="#en"/></scope>
>        <baseNameString>Abkhazian</baseNameString></baseName>
>    </topic>
>
> If we interpret the first topic's ID according to my "old" way
> of doing things, we get the combination of xml:base + "aa", or
>
>    http://www.topicmaps.org/xtm/1.0/language.xtm#aa
>
> Now, if we interpret it the way Jonathan is suggesting, we get
>
>    file:/usr/local/sgml/xtm/language.xtm#aa
>
> which is hardly what might be expected, or would be usable. 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.
>
> > | Now there's no way to do express the base URI of the XTM document
> > | without it falling victim to not sitting at its canonical server
> > | location.
> >
> > It works for all other URIs than those that are of the form
> >
> >   <xxxRef xlink:href="#foo"/>
> >
> > and also not for topic IDs, but as I wrote you can work around that.
>
> I didn't catch that -- how can you work around it?
>
> > | Ugh.  Why couldn't somebody talk sense into RFC 2396? Take it out
> > | into the alley and beat the hell out of it or something.
> >
> > Personally I think the solution in RFC 2396 is the right one. If you
> > follow a "#foo" link in your local copy of file X you don't want to
> > have to download it from the canonical location to resolve the
> > reference, since you already have the file locally.
>
> 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'd be like you and me taking a trip in a car, and me saying
> "could you hand me the coffee cup in the cup holder" and you
> reaching over to the next car in traffic and stealing their
> coffee. [okay, bad example, Friday-before-bank-holiday...]
>
> Murray
>
> ......................................................................
> Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
> Knowledge Media Institute
> The Open University, Milton Keynes, Bucks, MK7 6AA, UK
>
>     Boundless wind and moon - the eye within eyes,
>     Inexhaustible heaven and earth - the light beyond light,
>     The willow dark, the flower bright - ten thousand houses,
>     Knock at any door - there's one who will respond.
>                                      -- The Blue Cliff Record
>
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>