[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: URI resolver was Re: RDDL and XML Schemas Proposed Recommendation
Jonathan Borden wrote: > > This exists - the II URI resolver request. Is this URI equal/equivalent > > to this other URI I've given you. Allows you to map URLs to URNs to > > check equivalency. > > When you say 'exists': Is this something I can easily use and people can > easily setup? Potentially easy to setup, but to make this easy to explain, I think I need to go back over how URIs work. A URI is an identifier. All it does is say "Here is something that I want to name". That name may or may not exist in the real world. For the most part it is just a text string in memory. To find out what that identifier actually points to we need to resolve it. This process involves interpreting what the string means, stripping it into some component parts and then using those to decide a) How to look something up b) What we want to look up for that identifier c) Once we have looked it up, what protocol is needed to acquire it d) Interpreting the raw content that was sent back to us The first step is called resolving. We need to ask "the system" to find out what this identifier is so that we can do something with it. Inside the system, it must ask around to find out who is willing to resolve the string. This is termed the Resolver Discovery Service (RDS). [1] Once a resolver is found we then pass it the string and also tell it exactly how we want to resolve it. That is, we can ask it to supply us the concrete object, or a reference to another equivalent resource or to check if it is the same as some other resource. One of the requirements of the RDS RFC is that a resolver is not required to implement all request types. So you can set up a resolver that only turns URNs into URLs, or one that only resolves URLs into hard object instances. There are actually 9 different resolution possibilities provided by RFC 2168. Inside your web browser, there is already this system happening. A URL is a type of URI. The browser effectively does the resolving step of turning the URL you have typed into the location area into an object instance. Although typically it isn't implemented in a full resolver mode (have a look at java.net.URL for a good example), the basic principles are followed. Decide what the string is, strip it to pieces, contact the server with a given protocol and then interpret the bytes coming back. This is a single service - I2R (Identifier to Resource). The other 8 services are not implemented in your typical web browser. Now, getting back to the original point - is it hard to set on up? If you know what you are doing, and understand URI resolution mechanism - no. It is as simple as adding two more records to your BIND resource files and restarting named. The hard part is making sure you have the infrastructure in place to deal with the requests. Firstly, your end user application has to know how to deal with generic URIs. As I mentioned above, a typical web browser does not allow plugging in of generic URI resolver DLLs. It requires some trickery to get it to work properly. Think of how you might, from the GUI perspective, ask it whether this URI is equivalent to that URI. For custom application code you can use a thirdparty library. Some work has been done on a generic URI resolver library for libc but AFAIK it hasn't progressed much, if at all in the last few years. For the Java users, you can play with my library [2]. Secondly you have to have some form of database set up to enable the underlying requests to be resolved. Depending on the size of your application, this can be a big task. Usually this is mapped to lots of SQL requests. For example, resolving the URN urn:isbn:0071348131 requires someone to have a ISBN database that is publically available to check for information in. If you want equivalence checking then you will probably need a good history of old stuff. Next you need to put in the resolver front end. This could be DNS (requires addition of SVR and NAPTR records) or if you have a much simpler application then something like THTTP that does resolving over HTTP requests would work fine (my library has a THTTP RDS in it and there are couple of libs floating around for it. IIRC Apache has one in its contrib area). > Things like RDF allow you to make statements "about" resources without > needing to resolve the URI. Well that is an invalid statement. It is easy to prove it to be false because you may say something and then have the resolver tell you it is completely different. That is, these can only strictly be limited to a collection of hints until an authorative answer is given by actually resolving a resource. For example, that URN above, your RDF says that it is a comic book. If you resolved it you would find it is a technical book about Java network programming. > The resource that a URI identifies is distinct > from the "entity" that the URI may resolve to from time to time (the entity > is not guarenteed to be constant e.g. a stock price --very unfortunately > these days). A URI can specify a live resource. There is nothing saying that it cannot be returning a continuous stream. Just set your returned MIME type to user to indicate the correct information. URIs are not required to only resolve to text/plain, they can quiet easily be video/mpeg or some other x- scheme. If the URI resolves to an instantaneous stock price, then find a better resolver. Find one that returns you a reference to a stock ticker content type. The resolver I2Xs schemes allow you to resolve one identifier to multiple sources. To not do so is a failure on the part of the application writer and service writer to provide a reasonable service. What if your video server only returned you one frame of video each time you queried it? That's not particularly useful is it. The identifier is resolved to a streamed, live, resource. No reason why your stock price should be treated any differently. [1] The typical RDS implementation used by URI users only tend to use one RDS supplier - for example DNS. I've been doing work on and off over the last couple of years specifying how to use multiple RDS systems in a system. This acts in the same way that namelookups might use DNS, NIS or /etc/hosts or any combination of these. My URI libraries are the only ones capable of dealing with multiple RDS suppliers AFAIK. [2] OSS (LGPL) RFC compliant resolver library for all URI types - http://www.vlc.com.au/urilib/ -- Justin Couch http://www.vlc.com.au/~justin/ Freelance Java Consultant http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant -------------------------------------------------------------------
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|