- From: Kitchen Pages <jrobinson@kitchenpages.com>
- Date: Sat, 28 Aug 2004 18:30:51 GMT
- To: uri@w3.org
Re: URI vs Relative URI - I would have to state that the draft is clear in regards to "URI vs RELATIVE URI". My reason / example is : On windows if one is to rename a drive to a four letter name like "http" then the relative URI could not apply in an external lookup unless the application interface (like a web browser) knew how to handle it. (if someone would like to find out it would be wonderful but I would suspect the application interface would do a external lookup and not seek a drive named http mainly because of its pre-programmed methods in resolving such a request using the protocol stack) Entering http:.. into explorer shows that interfaces can do this as a form of voodoo magic, and the same with IniFiles.hpp as I suspect Inifiles.hpp adds a IP address or netbios path depending on condition (found or not). When it comes into external lookup's the draft is correct in my view as two or more parts are required - AUTHORITY://URI (with URL being apart of URI in this case) to be entered into the application interface by many methods. The interface then handles the request as it is passed through the protocol stacks for that application interface until a suitable or first found Authority is located and the resource is rendered in some manner. So to conclude my limited view - a renamed drive of http can not be resolved on many an application interface without first the application interface/s being programmed to handle such a request for a local resource or external resource of any kind - but a more lax system would in many cases show the local defined term(if any - a drive in this case would be returned as the network protocol is almost last). Some other examples have been posted which include defined terms by an application interface like that of Star Office for example by Sun ( file://c|path/name.ext). Another is a recent example of netbios domain name systems without a trail '.' would be seeking a relative URI on a local machine, then network broadcast if any, and finally external with a trail '.' to avoid the hosted domain and then go external (if the domain allows it)which is defined by the Domain the local machine happens to be in. The same can be applied in reverse for a external user looking up a resource on a local network/machine. The problem in my view comes from the protocol stacks used to define such terms used by application interface/s as these ideals are almost always left to the last thing of seeking the resource from anything due to the nature of changing resources, protocol stacks, application interfaces, and the Internet. In English a application interface should be made to lookup local things before going external (unless programmed otherwise like the voodoo magic above – or proxies, etc) and in that case the draft is correct in the way that I am reading it. However - there are more then likely better ways to explain this then I do here and I do not think the URI draft is the place for such. But a reference of some kind or another would be handy just to note that other methods like news, etc may be used before reaching the 'required' protocol authority depending on the application interface/s used.
Received on Saturday, 28 August 2004 01:28:20 UTC