Re: [Simple] Composition and elements

[Henning Schulzrinne <hgs at cs.columbia.edu>]

Paul Kyzivat wrote:
> 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.

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

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

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

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