[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: re URN, URL, URI
At 06:55 AM 10/22/98 -0700, Terry Allen wrote: >| DOUBT 1 :- URNs at this point are not widely used since there is no >| generally available resolution service. In case a resolution infrastructure >| comes up in time :- > >There is a generally available resolution mechanism, through DNS, but >it has not implemented except on a test basis so far as I know. URNs, >of course, may be useful within more constrained contexts. Note that >URN resolution won't happen for you without some effort on your part. In thinking about URN resolution and how it might work in practice, my conclusion is that if, for example, the DNS-based approach were implemented in generally-available places, then as part of your client configuration you would define what URN-resolution servers you want to use, just as you define DNS servers when you configure your IP network set up. Your client would then use these servers to determine what server or servers handle a particular URN name space. The browser would also have to know now to communicate with resolvers for particular URN name spaces, but this could be handled through simple plug-ins. For example, say I set up a URN namespace resolver on drmacro.com and an FPI resolution server on planetsizedbrains.com. A typical URN resolution session might go something like this: 1. On your client, declare "urnres.drmacro.com" as your URN namespace resolver 2. Your browser sees a URI like: "urn:fpi:+//IDN%20me.com//DOCUMENT%20mydoc//EN" and tries to resolve it to a resource. 3. Your client sees that the URI is in fact a URN (as indicated by the "urn:" prefix). It looks in its own configuration tables to see if any URN namespace resolvers are defined. It finds urnres.drmacro.com. 4. It sends the URN to urnres.drmacro.com using the DNS extensions outlined in RFC 2168. The URN namespace resolver looks up the namespace name "fpi" in its table and finds "fpires.planetsizedbrains.com". It returns this location to the client [at this point I'm not sure if the client or the URN resolver does the next part, but I think the intent is for clients to at least expect to be able to handle this part.] 5. The client sends the FPI to fpires.planetsizedbrains.com, using whatever protocol the resolver uses (but not HTTP). The FPI resolver looks up the FPI in its table and returns the URL of the resource to the client, assuming it finds it. 6. The client uses normal HTTP communication to attempt to resolve the returned URL to a resource. If I understand the URN mechanism, each URN namespace is responsible for defining the protocol for how resolution is done, i.e., the functional equivalent of HTTP. If I understand how these things are generally done, you would expect to define a socket-based service on some conventional port [but I'm really out of my depth at this point]. Viewed this way, it doesn't seem like it should be that big a deal to set up useful URN resolvers and services for resolving specific URN name spaces. The biggest barrier seems to be support on the client side for handling URNs to begin with. As various URN name spaces became more widely used and conventions develop, browsers would come with more built-in configurations for different name spaces, relieving users of the need to do the configuration themselves. I would expect browsers to provide a plug-in architecture for adding support for specific URN name spaces--how hard can it be? Am I totally off my nut here? Have I missed some critical detail that makes URN resolution harder than it appears to be by this analysis? I can't speak for Oasis, but it has already started exploring providing a Web-based FPI resolver--seems like there might be some resources there that could fund developing extensions to say Mozilla and a DNS server to provide the client/server binding you need for full URN resolution. It can't represent more than a week of programming time for someone who knows what they're doing (Joe Alfonso, where are you?). Note that in the case of pure FPIs in an XML context, the same infrastructure described above could still be used. The client would know that anything that is a public identifier that starts with "ISO", "+//" or "-//" is a public identifier and can use the same mechanism to look up the resolver for FPIs (assuming that a URN name space for FPIs has been registered or defined by convention). Or they might provide a mechanism for configuring FPI resolver services directly. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|