[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Demoting 'priority' requirement
Ahh, I completely misread that. I was thinking this was talking about consumers. In that case, I'm 100% in favor of changing this to MAY. Sorry for the confusion. -will On Aug 20, 2009, at 12:39 PM, Eran Hammer-Lahav wrote: >> -----Original Message----- >> From: Will Norris [mailto:email@example.com] >> Sent: Thursday, August 20, 2009 12:31 PM >> To: XRI TC >> Subject: Re: [xri] Demoting 'priority' requirement >> >> >> On Aug 20, 2009, at 12:01 PM, Eran Hammer-Lahav wrote: >> >>> I would like to change the use of the 'priority' attribute from >>> 'should' to 'may' as in: >>> >>> "When these elements appear more than once within the same parent, >>> XRD publishers *MAY* use the priority attribute to prioritize >>> selection of these element instances." >>> >>> The 'priority' attribute is the one thing about XRD I hear the most >>> complaints about. >> >> What is the actual complaint? Concern about the extra processing? > > No. The extra work by publishers when it makes no actual difference. > This is about publishers, not clients. > >>> While it is an important and powerful feature, I am not sure what >>> value is gained by making it a 'should'. The sentence above also >>> fails to point that multiple Links with different Rel values have no >>> use of priority if the Rel values do not repeat across links. >>> Changing it to 'may' solves that. >> >> Then we should change the sentence to reflect that fact if need be. >> The section on resource selection seems to do a pretty good job of >> pointing out that Links are first filtered based on a selection >> criteria and *then* sorted by priority. This is indeed an important >> feature, and the softer we word it, the more likely are to see it >> implemented inconsistently. If the XRD publisher goes to the effort >> of explicitly specifying a priority preference, then I do think that >> consumers **should** respect that priority. > > Again, I am only talking about the publisher part. The client should > still respect that explicit priorities set by the publisher.