Re: [Simple] Composition and elements

[Paul Kyzivat <pkyzivat at cisco.com>]

Henning,

I like what you have proposed below. I think there is one thing that 
will need to be fixed to make it work:

You suggest that tuple replacement is by identifier, and since tuples 
have tuple ids that works. But there will also be a need for override of 
person and device. (For same reasons.) And as currently proposed, person 
has no id because there is only supposed to be one, so that would need 
to be fixed.

And while device has an id, I'm not sure that can be the basis for 
replacement, since there are likely to be multiple publishers of 
information about the same device. (But I hate the idea of having both a 
"device" id and a "device entity" id.)

	Paul

Henning Schulzrinne wrote:
> I'm changing subject lines, as this is a separate topic.
>
> I'll start with my three basic requirements that, I believe, a useful 
> system has to have:
>
> (1) Well-defined semantics, i.e., the watcher has to know what the 
> document means (alternatives? uncertainty?). I hope that this is not 
> controversial.
>
> (2) Has to work with basic composition policies, not some fancy policy 
> which we have not even started to define. My basic composition policy 
> consists of addition (concatenation) and tuple replacement (by 
> identifier), at the tuple level. This seems like the most fundamental 
> policy that is upwards-compatible, i.e., doesn't do anything stupid even 
> if the composer has incomplete knowledge about the meaning of particular 
> elements. I call this elementary composition.
>
> (3) Corollary to (2): A composer has to be able to choose to allow the 
> watcher to make decisions and resolve conflicts, by basically relaying 
> information as received, possibly tagged.
>
> (4) Corolloary to (2): The system has to have a chance of working 
> correctly, i.e., without information loss, even if the composer does not 
> understand every element or attribute, e.g., extensions to RPID.
>
> This then leads to fairly simple rules:
>
> - There MAY be multiple <person> elements, with a number greater than 
> one representing uncertainty in the current state of the person described.
>
> - Things like <activities> are assigned to <person>'s, as proposed, 
> since that's what they describe.
>
> This solves the problem of elementary composition, since a device or 
> service that has knowledge about a person's activities, for example, 
> simply publishes a <person> tuple, which gets concatenated with those 
> produced by other sources. The watcher gets multiple pieces of possibly 
> conflicting information, but that simply reflects the real-life 
> uncertainty that we can't erase by referring to some magic, omniscient 
> composer that we'll build some day.
>
> Rules, such as authorization, can readily deal with the uncertainty, as 
> discussed earlier. ("Only apply rule if information is consistent.")
>
> These pieces can later be tagged with source information to allow the 
> watcher a more intelligent choice, but this can be deferred. (For a 
> plausible source tagging, this is likely to work better than having 
> multiple instants of a single sub-person element.)
>
> I'd be curious, besides general philosophy, what would break or be 
> ill-defined from a watcher perspective under this model.
>
> Henning
>
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


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