[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] How can http: URIs meet URN requirements?
Bill, I’m way behind in responding
to this, but just wanted to say that you raise good points throughout,
particularly the one about XRIs being used outside the Web space – it
reminds me yet again that this has always been a requirement of the XRI TC. I
also like the analogy that “XRIs are to data identifiers what XML is to
data” for stressing how they are independent of transport. =Drummond From: Barnhill,
William [USA] [mailto:barnhill_william@bah.com] Another strike against using http: schema URLs: HTTP transport
coupling. To me one of the biggest benefits of XRIs was independence of
resolution transport, i.e. XRIs are to data identifiers what XML is to
data. URIs/URNs could fit the bill, but there's a different resolution
mechanism for every URN namespace, if one exists for that namespace. XRIs
provided a logical resolution mechanism that could be mapped to any
physical transport, and was mapped to HTTP as an example. This means
you could have SIP-backed XRIs, XMPP-backed XRIs, Jini-backed XRIs, etc. I realize that some have the view that http: schema on a URL does not
imply use of HTTP to access that resource, but I find that
counter-intuitive. The schema on a URL serves exactly the purpose of a
mapping to an access protocol in my experience, albeit limited when
compared against that of the TAG. A use of a persistent abstract identifier within the http: schema space
also exists and has not caught on due to various issues: purl.org. So if we went the http: route we would in my opinion
be deciding on a vision of the data web that is an HTTP-based data
web. If that's what we really want to do then fine. It is definitely not what I
want, since my stuff centers on XMPP, AMQP, and SIP. I also feel the HTTP
data web will be a subset of the eventual data web and that we will see a
mashup of transport protocols as we see a mashup of different device types
becoming data nodes (i.e. data web nodes). Bill Barnhill
From: Peter
Davis the argument being made for accomplishing persistence in the http: scheme requires the a domain (at some arbitrary level), carry a policy of persistence. thus, if a 2nd level name (eg: xri.net) stated that it will guarantee persistence in it's namespace. thus http://peterd.xri.net will never get re-assigned.
I cannot say i fully agree, but that is the "solution" which has been discussed.
=peterd
On Aug 14, 2008, at 3:50 AM, Drummond Reed wrote:
> So here's the issue: the TAG has asserted (back during the OASIS > vote in > May) that all XRI requirements can be met by HTTP identifiers. While > we have > many other requirements beside persistence for which we do not > believe that > to be true, I don't think we need look any further than these very > simple > URN requirements. I've thought about this for hours and I cannot see > how > existing http: URIs can meet them. > > The logic is not complex: > > 1) The http: scheme does not require http: URIs to be persistent. > 2) The http: scheme does not define any syntax for indicating > persistence.
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]