On Fri, Aug 10, 2001 at 08:23:32PM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote:
> done by the user agent, in this case the Gimp, which delegates this
> to the appropriate plug-in depending on the type of the data. If some
> underlying library starts interpreting the fragment identifiers, then
> it violates the concept of URIs.
I don't think so at all - the rfc does not at all talk about software
layers.
> I do not like the idea of using different namespaces such as #gimp()
> when loading chunks from an object, because this is adding an
> artificial separation where there does not need to be one.
the w3c thinks otherwise - we already have a clash in the case of html,
where two rivaling systems exists (and can be distinguished because one
uses a clear idnication - xpointer).
> interpret the same URI differently, but I consider this to be a
> feature, not a bug. It is even an important feature.
It is also a feature that is against the words of the URI RFC. So when you
claim that this is in the spirit of the rfc you must know more than I do:
The semantics of a fragment identifier is a property of the data
resulting from a retrieval action, regardless of the type of URI used
in the reference. Therefore, the format and interpretation of fragment
identifiers is dependent on the media type [RFC2046] of the retrieval
result.
A fragment identifier is only meaningful when a URI reference is
intended for retrieval and the result of that retrieval is a document
for which the identified fragment is consistently defined.
I learned one very important point with regards to rfc's and internet
standards. If you break them you better had a very bad reason. And I don't
think we have a very good reason.
Please note that I don't consider "typing in uri's" a sensible user
interface, either. Do you really expect users to learn about fragment
identifiers when we could much better provide a nice-designed dialog
box. Internal procotocl is one thing, but the user input part is totally
seperate. Why provide "click the filename" interfaces if the user can just
type in file://xxx.
And as I understand it, "the ugly syntax like #subimage(xxx)" is your main
concern.
> within the WAD files even if it cannot edit the image data. If I were
> using the namespace that you recommend, then I would have to use two
> different URIs to access the same things in the two programs:
> doom.wad#gimp(F/F1/FLOOR7_2)
> doom.wad#deu(F/F1/FLOOR7_2)
why? both are floors:
doom.wad#floor(F/F1/FLOOR7_2)
otoh, if one plug-in loads the image and the other some othe rproperties
the fragments should be different - at least that's what the rfc
implies. I don't see "uglyness in internal representation" a compelling
reason to go against an rfc (esp. since I think the rfc is right ;).
> I could not simply copy the URIs between the two programs and expect
> them to do whathever they can do with the same data.
Obviosuly they specify different things.
> place. So the correct solution is to use a simple identifier for the
why?
> data that depends only on the file format, not on the application that
> is expected to use it:
> doom.wad#F/F1/FLOOR7_2
exactly, it should depend on the file format. however, there are different
way to specify images in a file format (maybe not in wad files which are
indexed by path but in other image types like photo-cd). and then it's not
at all obvious what the natural data format is. and in the future this
might be limiting extensions - look at html for exmaple.
> like it does when the user tells the Gimp to load an MP3 file or a
> compiled program.
in any case, I think "he who implements it has the final say". But remember
that my points were:
- exposing internal data representations to the user is unneecssary and
confusing for the majority of users - even fragment identifiers are
pretty much unknown by most users.
- if you grab public namespace you better name it - it might not bite you
today, but when it is too late you lost.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
