Wil (and OpenXRI users and XRI TC members
both):
This OpenXRI thread, which I am cc’ing
to the XRI TC because it is relevant there too, has reminded me of an issue
that I too ran across when writing up XRDS documents.
Currently we specify (in section 8.4 of XRI
Resolution 2.0 Working Draft 10, http://www.oasis-open.org/committees/download.php/17293/xri-resolution-v2.0-wd-10.pdf),
two different defaults for the “append” attribute.
The default value “none” is
specified for authority resolution and the default value of “local”
is specified for service endpoint selection.
Even though I helped write that section,
it has since struck me that:
a) It is unusual, potentially confusing (and not very wise) to specify
different default values for an attribute.
b) The more logical and intuitive default behavior of an absent or
null “append” attribute value would be “none”.
The reason we specified that “local”
should be the default behavior if the append attribute was absent or null was
that we anticipated that this would be the vast majority of use cases, i.e.,
passing on qxri paths to “dumb” web servers. However what I have
found in working on XRDS documents since we completed Working Draft 10 is that
this in fact is rarely the case, i.e., “local” is not chosen any
more than any other option.
So my proposal is simple: in Working Draft
11 (which we want to become the Committee Draft specification), we change
section 8.4 to specify that the default value of the “append”
attribute if it is absent or null is “none”. Thus if an XRDS author
wants a service endpoint URI to have the local part of the qxri appended, the
author needs to explicitly specify the value of the append attribute = “local”.
If anyone disagrees, please post.
=Drummond
From:
openxri-users-admin@lists.sourceforge.net
[mailto:openxri-users-admin@lists.sourceforge.net] On Behalf Of William Tan
Sent: Friday, April 28, 2006 3:01
AM
To: Mohit Raj
Cc: Drummond Reed;
openxri-users@lists.sourceforge.net
Subject: Re: [Openxri-users] New
Release 1.0-beta1
Hi Mohit,
I assume that you are referring to this chunk of code in the
resolveSEPToURIList() method:
ArrayList uris =
topService.getPrioritizedURIs();
for (int i = 0; uris != null && i
< uris.size(); i++) {
SEPUri uri = (SEPUri)uris.get(i);
String append =
uri.getAppend();
if (append == null)
append = SEPUri.APPEND_LOCAL;
urisOut.add
(constructURI(uri.getURI(), append, qxri));
}
The "if" clause is meant to provide the default append attribute
value of "local" if the attribute was absent. If the attribute was
present, its value will be passed to the constructURI method and acted upon
accordingly.
Thanks.
wil.
On 4/28/06, Mohit
Raj <mohitraj@gmail.com>
wrote:
Here's another tweak I made to the code to
get it running. Though not a big one, just a check more.
In the
Resolver.resolveSEPToURIList(), append attribute is only
being checked for its presence and the attribute value is not being
checked. Therefore, if the attribute is present but having the value as append="none" will
do the same thing as append
having any other value. In this am referring to the section 8.4 of WD 10
listing the append attribute values, dealing with the construction of Service
Endpoint URIs.
I made the following change:
if (append == null || append == "none")
Somebody pl. validate keeping in mind my
circumscribed knowledge of this.
-----Original Message-----
From: openxri-users-admin@lists.sourceforge.net
[mailto:openxri-users-admin@lists.sourceforge.net]On Behalf Of Drummond Reed
Sent: Thursday, April 27, 2006
11:45 PM
To: wil@dready.org; openxri-users@lists.sourceforge.net
Subject: RE: [Openxri-users] New
Release 1.0-beta1
Wil,
I've been tardy in sending a big thank high five to you and
the NeuStar team for doing this work to bring the OpenXRI code base up to the
XRI Resolution 2.0 WD 10 level. Great job!
As Mohit's question shows, it will be very good to start to
get it into active testing among the different members of the ecosystem. I
encourage everyone working with it to post any questions/feedback/suggestions
so we can get it to a very stable state as quickly as possible.
=Drummond
Hi all,
As you may have known, NeuStar has been building on the wonderful work done by
Epok to bring the OpenXRI code base up to XRI Resolution v2.0 wd10 level. In
particular, the XRDS (formerly known as XRIDescriptors) document format has
changed drastically, and so has the resolver logic and many supporting
functions. There are some new features such as service selection, nested XRDS,
new error handling, recommended API, etc.
We have implemented most of the resolver functionality, implemented XRI query
and fragment parsing, as well as created a dedicated proxy servlet according to
the working draft. The detailed ChangeLog can be found here:
http://sourceforge.net/project/shownotes.php?group_id=132761&release_id=411818
Due to time and human resource constraints, we had to focus on the client and
proxy server code. Therefore, the server code has been modified due to API
changes, but was NEVER tested and IS currently broken (it may compile but
certainly will not work.) The XRILookup tool can only support authority
resolution at this point (though the resolver API for service selection is
mostly functional.) We stress here that this is BETA (some might even argue it
is alpha) code and there is no guarantee that it will work at all. That said,
we at NeuStar will be using it ourselves and the code is evolving quickly
(while keeping the public API unchanged if possible).
SourceForge Project site: https://sourceforge.net/projects/openxri/
Binary tarball: http://prdownloads.sourceforge.net/openxri/openxri-j-1.0-beta1-bin.tar.gz?download
If you have any issues regarding the code please feel free to use the mailing
list or private email. Please feel free to contribute any modifications you
have made to any part of the code base and we will be happy to incorporate them
if they are beneficial to the community.
Thanks.
--
http://public.xdi.org/=wil
--
http://public.xdi.org/=wil