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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

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


Subject: RE: [xri-editors] Proposals for XRI Descriptor priority attribute


Gabe,
 
I agree that the interpretation of priority needs some discussion to determine how the client will resolve similar priorities.  From the registry perspective, all priorities will be returned in the XRID.  What the client does from there merits a general discussion.  How do we proceed with this?
 
As we (NeuStar Registry Team) have been doing analysis and high level design, we have produced some working documents to assist us in the process and communicate our understanding to Drummond.  These will serve as our launching point into development.  Drummond has mentioned that some of these documents, especially the XRID examples, will morph into other documents that will be posted and public.
 
Sharon
 
-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thursday, June 09, 2005 6:16 PM
To: Wodjenski, Sharon; Drummond Reed; xri-editors@lists.oasis-open.org
Cc: Chasen, Les; Zhang, Ning; Tran, Trung; Davis, Peter
Subject: RE: [xri-editors] Proposals for XRI Descriptor priority attribute

Since I am currently making changes in the XRI spec, let me continue with what I'm doing, based on your feedback.
 
I'm not comfortable with just leaving the interpretation of the priority attributes to the clients. I don't see any value in specifying the priority attributes without giving *some* semantics about how they are supposed to be interpreted. We should continue to talk about this aspect.
 
BTW, when you say " We can certainly put a priority attribute on the URI.  If we have general agreement, we will update the Object Model and the XRID examples document. ", what examples document and what object model are you talking about?
 
    -Gabe 
 
 


From: Wodjenski, Sharon [mailto:sharon.wodjenski@neustar.biz]
Sent: Thursday, June 09, 2005 12:20 PM
To: Drummond Reed; Wachob, Gabe; xri-editors@lists.oasis-open.org
Cc: Chasen, Les; Zhang, Ning; Tran, Trung; Davis, Peter
Subject: RE: [xri-editors] Proposals for XRI Descriptor priority attribute

Hi Gabe,
 
Thank you for your input on this topic.  I've embedded comments from the registry perspective below. 
 
Sharon
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thursday, June 09, 2005 1:34 PM
To: 'Wachob, Gabe'; xri-editors@lists.oasis-open.org
Cc: Wodjenski, Sharon; Chasen, Les; Zhang, Ning; Tran, Trung; Davis, Peter
Subject: RE: [xri-editors] Proposals for XRI Descriptor priority attribute

Gabe,

 

Great message. I'm in meetings down in Oakland the next two days so I'm going to defer on a response to Sharon and the NeuStar team (all copied on this message). I'll try to jump back into the conversation Friday afternoon.

 

=Drummond

 


From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Wednesday, June 08, 2005 4:16 PM
To: xri-editors@lists.oasis-open.org
Cc: Wodjenski, Sharon
Subject: [xri-editors] Proposals for XRI Descriptor priority attribute

 

Editors (and Sharon)-

    I have worked up some changes to the XRID schema in the XRI Resolution draft to support the concept of a priority attribute. Here are the main points of change - let me know if they meet your requirements or if you think we should be doing something else:

 

1) The following elements get priority attributes: Authority, Service, URI, Internal, and External. Note that while you didn't ask for the priority attribute on the URI element, it screamed for a priority attribute and is something we think would be quite useful.  
[Wodjenski, Sharon]  We can certainly put a priority attribute on the URI.  If we have general agreement, we will update the Object Model and the XRID examples document. 

 

2) The priority attribute has a type of xsd:nonNegativeInteger (ie 0+)
[Wodjenski, Sharon] Yes. 

 

3) It seems to me that the language should use SHOULD instead of MUST (that is, if an implementation has a good reason not to honor the priority attribute, that should not be considered nonconformant). I'd like to leave open the possibility that an extension or out-of-band information could modify the way in which a resolver chooses to use multiple elements with varying priority values.

 

4) As for the language instructing implementations on interpretation, I think it should be something along the lines of "Of elements of the same type, resolvers SHOULD use the element with the lowest priority value that can be used for the intended use. Elements which have equal priority SHOULD be considered equally usable and should be selected randomly for use - the order in which they appear SHOULD NOT be considered in selecting the use."

 

5) What rules exist for determining to use an element (Service, Authority, URI, synonym, etc) of a higher priority than one of a lower priority - for example, what rules do we specify about saying use priority > X if Service element(s) with X exist? Do you have to try to use all the elements of priority X before going to priority > X? Do you just have to try one? Does it matter on the type of element that has a priority attribute?
[Wodjenski, Sharon] The registry will return all of the priorities.  The client must determine how to use them according to client needs.

 

6) Since I put a priority attribute on the URI element, which may be the child of an element with a priority element as well (e.g. a URI element as a child of a Service element, both of which have prioirity elements), this may add a slight complication to the previous question. Whats the interaction between URI elements of varying priorities of a single containing element (say, "Service") vs. URI elements  of another parent of the same type (ie another "Service" element), where those parent elements have the same or differing priorities.
[Wodjenski, Sharon] Same as #5.

 

7) I'm assuming the default value for these priority calculations is 0 (so that not stating a priority attribute value makes it functionally the same as specifying priority 0 - the highest priority).
[Wodjenski, Sharon] In past discussions, we have said that the default value is 10, and that 1 is the highest priority.  However, if it makes sense to default to 0 and 0 is the highest priority, we can do that.  Would you want to default to the highest priority, or some medium priority?

 

     I want to make sure at least the use cases you guys (Neustar) have surfaced are adequately addressed by the schema changes and normative text we put in. I also want to head off any interpretation issues years from now ;-)

 

    -Gabe

 


__________________________________________________
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International
Phone: +1.650.432.3696   Fax: +1.650.554.6817

 



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