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


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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

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?

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

> I would also like to see the following text drop altogether:
> "Instead of omitting the attribute, however, it is recommended to  
> follow the standard practice in DNS and set the priority value to  
> 10. When a publisher wishes to indicate a very low priority, it is  
> recommended to use a large finite value (100 or higher) rather than  
> omitting the attribute."
> It doesn't add any value since publishers have all the tools needed  
> with the existence of the optional attribute to express their  
> preferences. Recommending defaults does not help and only produces  
> XRDs that are more complex than necessary.

I'm okay with dropping this, in fact I've had other people suggest  
that as well.  You're right that the existing processing rules are  
fine without this recommendation.


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