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,

 

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.  

 

2) The priority attribute has a type of xsd:nonNegativeInteger (ie 0+)

 

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?

 

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.

 

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

 

     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]