[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] Updated RPID

I think this approach may make things less expressive. If I provide
information about the person in the service tuple, how can I specify
that this information is really about the person? How can I
differentiate that information from information about the service?

I was unclear. With a bit more thinking (see last message), I think the better solution is to allow multiple <person> elements and have each service/device that actually derives this information include a <person> element in its publication.



As for the person tuple, I think a simple policy like "the latest
timestamp wins" will get you very far at least for information
explicitly published by the user. If the user explicitly publishes
information, he probably wants that information to be visible to
watchers.

This is one possible policy, but not necessarily ideal in circumstances where each publisher has pieces of the <person> information.


Automated publications are more complicated. For example, a calendar
application that publishes <person> elements should not override the
information the user explicitly has set. To solve this, some kind of
source information may be necessary. The watcher should be able to see
both the information published as well as the information published by
the calendar. One shouldn't override the other. But that doesn't mean
that they both can't publish person tuples. One could for example let
the composed person tuple contain two text notes, one from the calendar
and one from user.


I would rather have

<person source="calendar">
  <e:mood>bored</e:mood>
  <e:activities>
     <e:activity>meeting</e:activity>
   </e:activities>
<person>

<person sourceID="device17">
  <e:mood>anxious</e:mood>
  <e:activities>
     <e:activity>on-the-phone</e:activity>
   </e:activities>
</person>

That seems to reflect a "view" notion of the person, with each <person> representing one such view, better than collating all the items into one big bag of elements. That also makes it very easy for downstream elements to just ditch sources believed to be less reliable.


/Dag




_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple