RE: URI resolver was Re: RDDL and XML Schemas Proposed Recommendation

[Charles Reitzel <creitzel@mediaone.net>]

Sorry late to the thread, but I didn't see this issue discussed.

I agree that versioning is an important use of I2L resolution.  But perhaps the biggest area affected by URI equivalence issues is that of web caching.  XML Namespace URI "resolution" is one example of this problem.   But it also applies to most all web sites.

People rightfully don't want to go back to the originating host every time an Entity (in the RFC 2396 sense) is requested.  Many have said, configure a caching proxy server (or some variant, thereof).   At the URL level, this is all time tested and highly effective. 

Typically, static content (meaning, slowly changing) is expired in proportion to its age.  The newer it is, the sooner it will expire.  Dynamic content, to be cached at all, must be given an explicit expiration time in the future.  Proxies distinguish between static and dynamic content by explicit configuration (a regex on the URL) and, possibly, file extension (just before the ?).  There are more details, mostly relating to degrees of separation between the proxy and the originating host, but hopefully I have captured the most important parts.

What we need now is to describe how I2L "resolution" (as opposed to Entity "resolution") affects otherwise normal caching.  It does not have to be complicated.   The way I see it, the cached object identifier must relate to the cached Entity and, thus, is a URL.   The URL for a given URI may itself be cached.  But this is much more like to caching IP addresses for DNS names than caching retrieved Entities.

Important result: The notion of "What is a Resource" is application dependent  - not scheme, not protocol, not mime type - and is not relevant to caching, per se.  An application must be designed use the basic capabilities of the Entity Caching System to meet its requirements.  This result may apply to URI resolution in general, but I'm not sure. 

Another way to look at it: All existing web servers support the notion of name translation.   Thus, what is a URL to the client, appears to the server as a URI needing "resolution" to an Entity.   Much of what is being discussed in this recurring thread are various mechanisms to  push this I2L resolution out to the client - much like how domain names are resolved to (possibly dynamic) IP addresses and cached at the client.

take it easy,
Charles Reitzel



At 08:04 AM 3/27/01 -0500, Jonathan Borden wrote:
>Tim Bray wrote:
>
>>
>> At 10:14 AM 25/03/01 -0500, Michael Mealling wrote:
>> >Jonathan Borden wrote:
>> >> Using RDF you can make statements about URIs that cannot be
>> >> disproven by resolving the URI -- indeed there is no guarentee nor even
>> >> intention that a URI _can_ be resolved.
>> >
>> >RDF can do this, sure. But URIs don't know or care about RDF. RDF
>> >is simply one of a multitude of applications that use URIs. Each
>> >application uses them differently. In RDF's case it uses URIs to make
>> >some interesting and complex statements about URIs but that doesn't
>> >mean that URIs then inhereit those statements.
>>
>> I think you guys are straining at gnats.  What RDF does is
>> entirely appropriate, and it is a useful thing to make assertions
>> using URIs as hooks.  The subtleties about "resolution" are
>> lost on most people, which is I think just fine.
>
>I think unfortunately there exists alot of confusion around the whole area
>of URIs, what they 'mean', what they do in practice and what they are
>intended for. If these discussions help in any small fashion (and at the end
>of the day) to cut through this confusion then they are useful. If not, so
>be it.
>
>I think the problem is one of language and usage of terms. It is easy to get
>into a circuitous discussion if we are using different definitions of words
>such as "resolve" and "resource".
>
>Like in many/most endeavors, different people and groups develop different
>implementations aimed at solving similar problems. Michael et al. have been
>working at one end of the issue, and I've had the opportunity to read
>through a few of the _experimental_ RFCs (e.g. 2169,2483) and I see how
>Michael and Justin are using the term "URI resolution".
>
>My original question was in reference to issues regarding namespaces: How
>can I determine when two namespace URIs can be used interchangably? How can
>I determine when one namespace URI is intended to "replace" another? These,
>I _think_, are practical questions without definitive answers. Eriv VdV has
>been working with the same issues in 'examplotron', has requested and I have
>added a new RDDL purpose to assist with this.
>
>http://www.rddl.org/purposes#prior-version
>
>(this purpose indicates that the URI in question is a 'prior version' of the
>base URI of the RDDL document)
>
>Now I admit the above referenced exchange did get theoretical and obtuse --
>and on rereading I'm not sure that I understand it myself -- however what it
>_did_ highlight to me at least, is the fact that different people and
>communities use relatively common terms in different ways, and you may think
>you both are talking about the same thing when in fact you aren't.
>
>But in the most practical fashion, this is about versioning. Since we are
>talking about 'attaching' code to namespaces, these issues become important.
>What do you do with a new version of some code 'attached' to a namespace.
>What about new versions of libraries referenced by this software. New
>namespace? What about the old documents? Solving them isn't always as
>straightforward as the simplest solution provides. Anyone who has ever been
>in dll hell understands this.
>
>-Jonathan


take it easy,
Charles Reitzel