Limitation of <sdshare:resource> to exactly one per fragment - Why?

[heuer]

5.1.5. says:

This element [sdshare:resource] MUST occur exactly once as a child element of each entry.

I wonder why this limitation was introduced. In an older spec it was allowed to mention 1..n subjects

If the subject A and B are modified within a transaction the server has to a) produce two fragment entries which point to the same fragment with different resource elements b) divide the transaction into two parts and produce a fragment which modifies subject A and one fragment which modifies B

I wonder if (b) is realisable and if (a) desirable since the fragment feed becomes longer and the client would perform the deletion process of section 5.2.3. for the same fragment for subject A and B unless it is smart enough to recognize that the Atom entry for A and B point to the same fragment (a client could recognize it if the Atom entry id is the same or if the link is the same).

Basically my question is: What are the reasons for the "exactly once" limitation? :)

[larsga]

I have to admit I forget the exact rationale. We should have written it down. Partly it was to make the spec simpler to understand and implement.

If the subject A and B are modified within a transaction the server has to [...]

Well, not really. It just has to keep track of when A and B changed. A fragment isn't necessarily a unit of change, it's just a unit of data, wherein some parts have changed.

But it's true that we could make the element repeatable, and extend the update algorithm slightly.

[gra-moore]

The feed isn't a list of the transactions that have occurred, it simply lists the things that have been modified. So the challenge (a) and (b) doesnt really exist. For every transaction that occurs you just need to remember which things are affected. Then later you are asked for the state of that thing.