On Thu, Aug 09, 2001 at 12:42:33AM +0200, Jens Lautenbacher <[EMAIL PROTECTED]> 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
> why should any future app that groks uris be unable to parse
> 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 +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
Gimp-developer mailing list