Proposed accounting for public comments on XRI Syntax 2.0

["Drummond Reed" <drummond.reed@cordance.net>]

Following is a first draft of the proposed accounting for public comments on
XRI Syntax 2.0 as required by section 3.4(g) of the OASIS TC process.

XRI TC members, please read this over and send ANY feedback to the list
prior to noon Pacific time on Monday. Gabe and I will then prepare the final
draft.

***** PROPOSED ACCOUNTING FOR PUBLIC COMMENTS - FIRST DRAFT ******

Mary:

Per section 3.4(g) of the OASIS TC process
(http://www.oasis-open.org/committees/process.php#3.4), following is an
accounting for the public comments received on the XRI Syntax 2.0
specification during the following review periods:

1) XRI Syntax 2.0 Committee Draft 01 had a 30-day public review starting
March 15, 2005, with a 17-day extension starting April 13, 2005, ending
April 30, 2005.
(http://lists.oasis-open.org/archives/tc-announce/200503/msg00005.html). 

2) XRI Syntax 2.0 Committee Draft 02 had a 15-day public review starting 18
October 2005, ending 2 November 2005.
(http://lists.oasis-open.org/archives/tc-announce/200504/msg00004.html).


The following comments were received during the first public review period
on XRI Syntax 2.0 Committee Draft 01 (note that this public review period
also included XRI Resolution 2.0 Committee Draft 01 and XRI Metadata 2.0
Committee Draft 01.)

#1) Jerome Jump, Epok
http://lists.oasis-open.org/archives/xri-comment/200503/msg00000.html 

#2) Dan Connolly, W3C
http://lists.oasis-open.org/archives/xri-comment/200504/msg00000.html

#3) W3C Technical Architecture Group (TAG)
http://lists.oasis-open.org/archives/xri-comment/200504/msg00003.html
http://lists.oasis-open.org/archives/xri-comment/200505/msg00000.html 

#4) Mark Baker, Coactus
http://lists.oasis-open.org/archives/xri-comment/200504/msg00004.html

One comment was received during the second public review period on XRI
Syntax 2.0 Committee Draft 02:

#5) Norm Walsh, Sun
http://lists.oasis-open.org/archives/xri-comment/200510/msg00000.html


XRI TC RESPONSE

Comment #1 from Jerome Jump of Epok was relative to the XRI Resolution 2.0
specification, which is a not at this time being submitted for consideration
as an OASIS Standard. Mr. Jump pointed out a minor errata and suggested
alternative formatting of the XML examples in the specification. Both of
these have been incorporated in a subsequent working draft of XRI Resolution
2.0.

Comment #2 from Dan Connolly of the W3C made the suggestion that the OASIS
XRI TC should register "xri:" as a URI scheme with the IETF as part of
preparing for wide deployment. Technically the XRI Syntax 2.0 specification
creates a new identifier that has a defined transformation into an IRI
normal form and a URI normal form. The XRI TC does intend to pursue IETF
registration of the xri: scheme for XRIs in IRI and URI normal form once XRI
Syntax 2.0 reaches OASIS Standard status.

Comments #3 from the W3C TAG was subsequently referenced by comment #5 from
Norm Walsh and is discussed below.

Comment #4 from Mark Baker was a very brief statement arguing against the
deployment of any new abstract identifier scheme and favored reuse of the
HTTP URI scheme.

The W3C TAG's comments focused almost exclusively on the use of XRIs to
solve the problem of persistent identification. They felt that the ways in
which XRIs solve this problem using an additional layer of indirection can
also be achieved using HTTP URIs, and that the costs of deploying the XRI
scheme for persistent identification would not be overcome by its benefits.

The TAG summarized their comments as follows:

"The recommendations that we have documented in Architecture of the World
Wide Web, Volume One state that "A specification SHOULD reuse an
existing URI scheme (rather than create a new one) when it provides
the desired properties of identifiers and their relation to
resources." [2] In this case, a properly managed and supported use of
the existing http scheme, based on the excellent analysis in your
documents, does have the desired properties and can provide the same
functionality without the loss of interoperability which would
accompany a new scheme."

[2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-scheme

The XRI was chartered in January 2003 because, after considerable research,
its organizers concluded that no URI scheme, including the HTTP and URN
schemes, provided "the desired properties of identifiers and their relation
to resources" when the desired properties were those of uniform abstract
identification, i.e., a consistent way of identifying resources independent
of domain, location, application, and interaction method.

In particular, the HTTP URI scheme did not (and could not) fulfill this
requirement because the vast majority of identifiers produced using this
scheme: a) are concrete identifiers (identifiers tied to a particular
domain, directory, application, or device), and b) have (by definition) a
specific method of interaction (HTTP). As further evidence, one reason the
URN scheme (the closest thing to a URI scheme for abstract identification)
was developed at the IETF was because the HTTP URI scheme did not include
syntax for uniform persistent identification of resources.

More importantly, however, persistence is only one requirement of uniform
abstract identifiers (and in fact one that does not apply in many use
cases.) Six additional categories of requirements were enumerated in the XRI
TC requirements document.

http://www.oasis-open.org/committees/download.php/2523/xri-requirements-and-
glossary-v1.0.doc 

Two of the most important are:

1) Uniform cross-context identification. This is the requirement to be able
to share identifiers across hierarchies (multiple domains and applications)
with uniform interpretation (a directory concept known as polyarchy.) XRI
Syntax 2.0 provides a specific construct -- cross-references -- for this
purpose. Cross-reference syntax is particularly useful with identifier
metadata; so useful that the XRI TC publishes an entire specification (XRI
Metadata 2.0) for the purpose of establishing uniform metadata for
expressing the language, date, and version of an identifier. 

http://www.oasis-open.org/committees/download.php/11854/xri-metadata-V2.0-cd
-01.pdf

Furthermore, since the public review of XRI Syntax 2.0 Committee Draft 01 in
March, new participants have joined the XRI TC expressly to develop metadata
for expressing the type of an identifier. This new form of metadata can help
solve longstanding interoperability problems when legacy identifiers of a
specific type (OIDs, UIDs, distinguished names, usernames, etc.) need to be
federated across enterprises.

http://lists.oasis-open.org/archives/xri/200509/msg00048.html
http://lists.oasis-open.org/archives/xri/200509/msg00108.html (see topic #3)

2) Uniform federation. The generic URI syntax and the HTTP URI scheme
support delegation syntax only in the authority segment, and then only for
IP addresses and DNS names. XRI Syntax 2.0 provides uniform federation
syntax for both persistent and reassignable identifiers at any level of
hierarchy. This capability is particular useful in conjunction with XRI
cross-reference syntax, as it enables identifier authorities at all levels
of hierarchy to delegate identifiers using shared "dictionaries".

As stated in the XRI TC's charter and requirements document, the goal of the
XRI TC was to create a single uniform identifier syntax that met these and
four other categories of requirements. Such a syntax could lead to the same
widespread benefits from a uniform abstract identifiers that the Web
currently enjoys from URIs and IRIs as uniform concrete identifiers. We
believe XRI Syntax 2.0 fulfills these requirements and recommend its
advancement to an OASIS Standard.