Updates: processing order of replace/delete/add?

[sknebel]

https://www.w3.org/TR/micropub/#update-p-3 says

The request MUST also include a replace, add or delete property (or any combination of these) containing the updates to make.

An order of delete->replace->add seems to make the most sense (under the assumptions that no listed operation should be instantly made redundant by another part of the request), but this is not clearly specified. Is that intentionally not specified? I guess I'd like to see a clarification either way (either a warning that it can not be relied upon by clients, or a rule for servers)

[tantek]

@sknebel do you know if any existing implementations do the order you expect? Is there a test for this so we can see if existing implementations agree or not? Either way we should document (at least in this issue) what we are seeing from existing implementations, and then perhaps start an errata document that describes either the rough consensus among implementations (if there is a consensus), or the "makes the most sense" if implementations are willing to change.

[dissolve]

for sending in inkstone i specifically avoid this case as it doesn't make sense to add and delete and replace all at the same time. If you are doing more than one operation, its far simpler to just replace the entire contents.

Add and delete order doesn't matter as you can add and remove different values, if its adding and deleting the same value it is clearly an error, and delete should take priority.

If you are adding and/or deleting and replacing the entire contents, the replace is what i use as it doesn't make much sense to add and remove things while you are also replacing the entire thing.

So i suppose my order in receieving is add then delete then replace (highest priority)

[aaronpk]

The only time this actually matters is when you have two actions that specify the same property-value combination. e.g. (pseudocode)

add: syndication=example.com
delete: syndication=example.com

Unless an order for add/delete/replace are specified, this may result in the value being present or not present depending on how it's implemented. However, I can't think of a valid use case that would warrant a client sending that.

In any other case where differing properties and values are used, the order doesn't matter, it will always result in the same outcome.

I propose adding some clarifying text to the Update section explaining that servers may have undefined behavior if multiple operations of the same property-value combination are sent in an update request.

[dissolve]

:+1: note that it is undefined

garbage in, garbage out

[tantek]

Perhaps consider @sknebel's suggestion for a post 1.0 proposed errata and see if there is implementer consensus on it.

[sknebel]

I thought there was a use-case for sending a combination, but now I'm pretty sure I had confused details of updates and deletes back then – so I agree that just noting it as undefined is fine.

(I have implemented the order in my own endpoint as I described)

[aaronpk]

Thanks. I've added this text here: https://micropub.net/draft/#update

Please close the issue if this addresses the concern for you!