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. -- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
