RE: PIDF for buddylists

On 10 June 2002 23:51, Paul Kyzivat wrote:
> One thing that might be a problem would be indicating that a response 
> has had filtering and/or differencing applied. Some of it could be 
> handled as extension values in tuples, but I can foresee a need to 
> know this at the <presence> level too. One possible change to the 
> current proposed PIDF format that might help here would be to make 
> explicit provision for extension values within <presence> itself. This

> would look like:
> 
>       <xs:complexType name="presence">
>          <xs:sequence>
>             <xs:element name="tuple" type="tns:tuple"
maxOccurs="unbounded"/>
>             <xs:element name="note" type="xs:string" minOccurs="0"
>                 maxOccurs="unbounded"/>
> *           <xs:any namespace="##other" processContents="lax"
minOccurs="0"
> *              maxOccurs="unbounded"/>
>          </xs:sequence>
>          <xs:attribute name="entity" type="xs:anyURI" use="required"/>
>       </xs:complexType>

This has been mentioned in the past, but AFAIK, this is the first
concrete example of *why* we should make it. In the past, I think I've
probably stuck with the letter of 2778 using our current approach, but
on the basis that this is such a small change, has been requested a few
times, and generally looks like a good idea, I think we should adopt it.

> Another approach for handling this kind of change would be to simply 
> define a different presence document type for representing diffs and 
> multilevel presence status. Clients wanting to use it would then have 
> to be prepared for servers that can't handle it, by falling back to 
> the old PIDF.

I'd like to avoid that if possible - I think we should make the change.

Adrian.





  [reminder: [email protected] for non-technical discussions, please]