Subject: [Simple] Composition and elements

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Oct 2004 16:48:16 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Oct 2004 18:21:19 -0400

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Oct 2004 18:51:38 -0400

> has no id because there is only supposed to be one, so that would need 

Definitely - everything needs an id, by analogy. Generally probably a 
good idea, for regularity.

> "device" id and a "device entity" id.)

Pulling out my favorite database analogy, there seem to be four 
operations that seem to be sufficient in SQL: INSERT, REPLACE, UPDATE, 
DELETE. If we model those, we should be on solid ground, given that 
there hasn't been a new operation in about two decades.

Standard database design argues for having an (auto-increment, 
typically) primary-key identifier that has no application semantics and 
is simply guaranteed to be unique across records. (I've designed lots of 
databases, and each time I violated this assuming that some data field 
would be a good identifier, too, I regretted it later - this as an aside 
to the URI-as-identifier discussion.)

The tuple/device/person identifier is simply that - a record identifier 
or primary key, with no semantics except uniqueness for a single 
presentity. It should not necessarily reflect a single physical device, 
person or tuple.

With that, we can have simple composition rules:

INSERT - add to records; error if a record exists with the same identifier
REPLACE - replace whole record if there's an existing primary key
DELETE - obvious
UPDATE - replace only those elements (fields) that are actually 
contained in the update record and leave the rest alone

Thus, two publishers on a device would typically do a logical UPDATE in 
the composer and things would work as long as they don't have 
conflicting views of the device that alternate on each publication. The 
same might be true if you want to do latest-wins for a person.

We don't have to or want to design the details of composition now, but 
I'd be worried if we believed that simple semantics which have worked 
well in a closely related application should not form the basis for such 
semantics, even if there are lots of smarter actions defined by somebody 
later.

Summary: Device label should be separate.

As an aside: There is a separate reason for that, having to do with the 
difficulty of defining a unique device identifier discussed earlier. 
Once you remove the role as an XML element identifier, you could, for 
example, have *several* (UUID) identifiers which each have the property 
that they uniquely define the device, but you might not be able to agree 
on which type of identifier to use in general.

This greatly increases the chance that a smart composer can recognize 
that two device tuples actually refer to the same piece of hardware, 
since one of their identifiers matches. (Trivial example: assume we 
can't agree whether some hostid-based or MAC-based ID should be used 
since this will differ for each device type. In my approach, each device 
publisher would include *all* the unique IDs it can get at, increasing 
the likelihood that one type will be in common.)

This is obviously a separate discussion.

Henning