OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: How can http: URIs meet URN requirements?


RE the ongoing W3C TAG discussions
(http://lists.w3.org/Archives/Public/www-tag/, look for [XRI] in the
header), I have reviewed the threads from when I was on vacation and have
one thought that I want to run by XRI TC members on tomorrow's telecon
before posting to the TAG list.

The thought regards persistence, which as we all know is just one of many
requirements of XRIs, but which is a simple enough requirement that has long
been embodied by URNs.

In this area, the XRI TC had two functional requirements in common with
URNs: 

1) To be able to express a fully persistent identifier as defined in section
2 of RFC 1737, Functional Requirements for URNs:

     Persistence: It is intended that the lifetime of a URN be
     permanent.  That is, the URN will be globally unique forever, and
     may well be used as a reference to a resource well beyond the
     lifetime of the resource it identifies or of any naming authority
     involved in the assignment of its name.

2) To be able to recognize a fully persistent XRI purely by inspection,
i.e., without requiring resolution of any kind.

URNs meet both these requirements very easily: 

1) All identifiers using the URN scheme are required to be persistent by
definition.
2) All URNs can be unambiguously recognized purely by the urn: scheme
prefix.

With XRIs it can't be quite that simple because XRIs by definition encompass
both persistent and reassignable abstract identifiers (or any combination of
persistent and reassignable subsegments). But XRIs still satisfy the same
two requirements with just one modification:

1) An XRI is fully persistent if it consists entirely of persistent
subsegments (subsegments that are delimited with the ! character).
2) All XRIs in URI normal form can be unambiguously recognized by the xri:
scheme.

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.

Therefore, if an http: identifier is to serve the same function as a URN,
and this quality is to be recognizable purely by inspection, it must be done
with some additional semantics beyond the scope of the http: scheme.

QED. Unless, of course, I'm missing something, which is why I'm posting this
to the list and asking for feedback. If you see a hole in this logic, by all
means please do post a reply (especially if you can't make tomorrow's
telecon).

Note that I'm _not_ saying that such semantics cannot be added to an http:
URI. Indeed, that's just what we did with HXRIs. In fact on the W3C TAG
discussions John Bradley has coinied the term "http: subscheme" to describe
this URI-scheme-to-http:-URI mapping. I'm a big supporter of this because it
makes sure all XRI-addressable resources can be fully exposed/integrated
with the http: information space.

But I think the URN requirement issue alone shows why we still need the
functionality of the xri: scheme. In fact, it appears that it is this type
of requirements that is specifically in section 1.1 of RFC 3986 as it
explains the rationale for URIs and different URI schemes:

   This specification does not place any limits on the nature of a
   resource, the reasons why an application might seek to refer to a
   resource, or the kinds of systems that might use URIs for the sake of
   identifying resources.  This specification does not require that a
   URI persists in identifying the same resource over time, though that
   is a common goal of all URI schemes.  Nevertheless, nothing in this
   specification prevents an application from limiting itself to
   particular types of resources, or to a subset of URIs that maintains
   characteristics desired by that application.

*******
Thoughts?

=Drummond 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]