Re: [Tm4j-developers] Merge utility now uses TopicMapProvider; possible URI resolution issue in TopicMapProviderBase

[Kal A. <ka...@te...>]

On Monday 10 June 2002 06:00, Florian G. Haas wrote:
> Hello,
>
> On Friday 07 June 2002 16:40, Kal Ahmed wrote:
> | This lack of source URL is a big hole in the InputStream interface IM=
HO.
> | But given that we can't change that (unless anyone knows a developer =
in
> | the Java team ;-), then I think that there needs to be some default r=
ules
> | for assigning a URL to the stream. I propose that :
> |
> | 1) each file can be assigned a base url with a parameter following th=
e
> | file name:
> | org.tm4j.topicmap.cmd.Merge -o output.xtm foo.xtm -baseurl
> | http://www.mysite.com/tms/foo.xtm bar.xtm -baseurl
> | http://www.mysite.com/tms/bar.xtm
> | This has the advantage that I can use local copies of the files for t=
he
> | merge process yet still have them treated as if they originated from =
the
> | online sources.
>
> Good idea, but it can't be done using JArgs (as far as I know). So we w=
ould
> throw out much of the flexibility we've gained using JArgs by having to
> write our own parsing routine again. Or is there an alternative to JArg=
s
> which does support the structure you propose?
>

I'm not aware of any alternative to JArgs that might support this form of=
=20
command-line. But can't we use JArgs to parse all the options before the=20
input file names and then parse the remaining ones (after all we are only=
=20
looking for a  (filename [-baseurl url])* pattern so it might not be too =
hard=20
to do...

> | 2) if no base url is specified and the input source is specified on t=
he
> | command line generate the URL from the input file name, so "foo.xtm"
> | would be resolved as a File then you can use File.toURL() to get a
> | locator for the input source. "http://someurl.com/foo.xtm" would fail=
 to
> | resolve as a file, so you could convert that to a URL, get the
> | URLConnection for the source and use the URL itself as the base url
> |
> | 3) if no base url is specified and the input source comes from a pipe=
,
> | then use some default URL  (could it be based on the current working
> | directory ?)
>
> OK, but TopicMapProviderBase doesn't support any of that yet. It needs =
an
> overloaded readTopicMap() method which accepts and InputStream and a St=
ring
> representing a system ID.
>

I was thinking that the base url would be used to create a Locator object=
,=20
then we can use TopicMapProvider.addTopicMap(InputStream, Locator, TopicM=
ap).

> Still, even if it's useless, I suggest that we at least drop Sun a note
> that something like a URLConnectionInputStream is more than needed. We'=
re
> probably just a few out of thousands, but at least it's worth telling t=
hem.
>

I guess that it wouldn't hurt to do that. Perhaps we all should ;-)

Cheers,

Kal

--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy

e: ka...@te...
p: +44 7968 529531
w: www.techquila.com