RE: [Openxri-users] Proposal to standardize default value for append attribute

Wil, I agree with your first point and
have made a note to add that text to Working Draft 11.

 

Regarding the second one, about what the
default value should be, this is one of those places where I simply feel we
made a mistake in Working Draft 10 and we should correct it as early as we can
or else more and more XRDS developers and implementations are going to be
written assuming a default value of the append attribute that was a poor
choice.

 

In other words, nip the problem as early
in the development stage as possible. This is *exactly* the kind of problem that Working Draft 10 is supposed
to uncover. Thankfully, it’s the only normative issue that’s come
up so far – everything else is simply non-normative changes to text to
better understand/clarify the spec.

 

How do others feel? Is this a problem we
should “nip in the bud”?

 

=Drummond 

 

From: William Tan
[mailto:] 

Sent: Friday, April 28, 2006 10:42
AM

To: Drummond Reed

Cc: Mohit Raj;
; 

Subject: Re: [Openxri-users]
Proposal to standardize default value for append attribute

 

Drummond,

I agree that the append attribute default value being different for different
stages of resolution is confusing. However, I think the confusion lies in why
is append="none" for authority resolution? Authority resolution uses
its own rules for URI construction, which is to append the next unresolved
subsegment(s). That process is not the same as append="none". I'd
vote for putting in text to the effect of "URIs within a Service element
which is meant to be used for authority resolution SHOULD NOT have the append
attribute. If an append attribute is present, its value MUST be ignored by the
client for the purpose of XRI resolution." At least for resolution as
defined in this specs. 

I don't see a need to change the default value of "local" (though I
agree that "none" seems more intuitive); there are equally valid use
cases for each of them, and I'd prefer having a more stable spec to develop
against unless there are serious concerns. 

wil.

On 4/29/06, Drummond
Reed <>
wrote:

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: 
[mailto:] On Behalf Of William Tan

Sent: Friday, April 28, 2006 3:01
AM

To: Mohit Raj

Cc: Drummond Reed; 

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 <>
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: 
[mailto:] On Behalf Of Drummond Reed

Sent: Thursday, April 27, 2006
11:45 PM

To: ; 

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: 
[mailto:] On Behalf Of William Tan

Sent: Friday, April 21, 2006 10:40
AM

To: 

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

-- 

http://public.xdi.org/=wil