[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] Proposals for XRI Descriptor priority attribute
Mike, I'm not sure any of the documents would be helpful. They are internal documents for the GRS design and don't cover anything from a client perspective, or address the semantics of the priority attribute. About the best I could offer would be some example XRIDs to use for discussion. Sharon -----Original Message----- From: Lindelsee, Mike [mailto:mlindels@visa.com] Sent: Monday, June 13, 2005 6:19 PM To: Wodjenski, Sharon; Wachob, Gabe; 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 Would any of those documents serve as a starting point for this discussion? I tend to agree with Gabe that if we are going to specify a priority attribute, we should also specify the semantics of that attribute. At the very least, this seems needed for interoperability. As a separate issue, if this topic is going to take some discussion to work through, does the current schedule for publishing the specs and voting still make sense? Mike >-----Original Message----- >From: Wodjenski, Sharon [mailto:sharon.wodjenski@neustar.biz] >Sent: Friday, June 10, 2005 7:13 AM >To: Wachob, Gabe; 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 > >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]