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: Proposal to standardize default value for append attribute


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:

Wil,

 

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)

     if (append == null || append == "none")

 

Somebody pl. validate keeping in mind my circumscribed knowledge of this.

 

Thanks,

Mohit

 

 

 

-----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

 


From: openxri-users-admin@lists.sourceforge.net [mailto:openxri-users-admin@lists.sourceforge.net] On Behalf Of William Tan
Sent: Friday, April 21, 2006 10:40 AM
To: openxri-users@lists.sourceforge.net
Subject: [Openxri-users] New Release 1.0-beta1

 

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



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