I'm not sure who to contact on the list but I've gotten this same message about 30 times over the last two days. Any way to clear it out. I guess some server somewhere doesn't think I'm getting it :) Thanks. Chris On Thu, 9 Aug 2001, Marc wrote: > On Thu, Aug 09, 2001 at 12:42:33AM +0200, Jens Lautenbacher <jtl@xxxxxxxxxx> wrote: > > yes of course, but where's the difference in our problem here? > > that the user agent is the gimp and might interpret fragment identifiers > - at leats some underlying library might (and should) do that. my point > is that we shouldn't just claim fragment identifiers as being "plug-in > namespace". > > > why should any future app that groks uris be unable to parse > > these??????? > > > > http://www.mozilla.org/images/mozilla-banner.gif#eeek > > > > when I type this in a web browser, there's no problem. There's in fact > > no problem with any app that correctly handles uris. > > Wrong. Some app might validly try to interpret eeek as something strange. > for example, some (bad) app might want a number there and might display > nothing. For some deifnition of correct this is correct, but... The > problem is that nobody knows how to interpret that "eeek" except the gimp, > and using a more verbose form at leats might give a clue that a subimage > with name is meant. > > > And not only does it not make a problem, the outcome is also the > > expected --- it loads the gif. > > You are arguing backwards. That current technology is quite low-level does > not mean that it won't improve in the future. You are arguing that ua's > basically thwo away fragment identifiers on images, which is the case > currently, but I don't think that's what people want. I mean, the fragment > identifier is there for some reason so ignoring it is not nice. > > > GIMP on the other would maybe throw a warning for this uri, as there's > > no "subimage" of any sort in this gif. But that's just the added value > > we get because we decide what a fragment means for e.g. a wad file. > > Indeed. Why not do it as others and mark our namespace with something like > subimage(xxx) or gimp(xxx)? > > > As the "meaning" of a fragment is left to the media type (and the UA) > > there will just _never_ be a problem. > > Sorry, I really cannot follow you here. When that logic is applied to, > e.g. URI's or form data sets I get this sentence: "As the 'character set > detection' of a URI or form data set is left to the server, there will > just _never_ be a problem." Sorry to disagree, but I think that's just > plain backwards: we need _less_ ambiguities, not more. > > -- Chris the Christianfreak http://christianfreak.net May a hundred thousand midgets invade your home singing cheesy lounge-lizard versions of songs from The Wizard of Oz.
