indicating information up-to-dateness

[juliuste]

I think it would make sense to introduce an attribute to FPTF@2 objects that indicates the up-to-dateness of the given information. This would enable us (e.g.) to provide a combination of static and realtime data in FPTF (where more up-to-date information overwrites older information).

Such an attribute could for example be called asOf, effective or updated and would contain a date string. It could also be required since this information is basically almost always available, as far as I know?

Opinions?

[derhuerst]

Sounds good. I'd add a general section mentioning this optional, but "reserved", field.

There are multiple properties of a data item that might be interesting:

• When has the item been created?
• When has the item been updated the last time?
• For how long is the item valid?

Unfortunately, different properties are relevant.

[juliuste]

Sounds good. I'd add a general section mentioning this optional, but "reserved", field.

Why not make it required? Or are you talking about FPTF@1?

There are multiple properties of a data item that might be interesting:

• When has the item been created?
• When has the item been updated the last time?
• For how long is the item valid?

I certainly agree that we should/could add some optional property for indicating how long an item is valid, but I don't see the necessity to separate the time an item has been created from the time one has been updated. I think the more general approach would just be to assume that the ”newer“ of two objects with the same id would be the more up-to-date. (Example: A feed of stopover objects where you would ”update“ an object by publishing a new one with the same id but a more recent date and e.g. updated departure information).

[derhuerst]

Sounds good. I'd add a general section mentioning this optional, but "reserved", field.

Why not make it required? Or are you talking about FPTF@1?

Because I'd like to avoid to extend the set of required fields beyond what's necessary, in order to keep the barrier to adopting it low.

I think the more general approach would just be to assume that the ”newer“ of two objects with the same id would be the more up-to-date. (Example: A feed of stopover objects where you would ”update“ an object by publishing a new one with the same id but a more recent date and e.g. updated departure information).

This sounds like a sensible and intuitive way, but I'm not sure we can fit the semantics of all APIs into this format.

[juliuste]

Because I'd like to avoid to extend the set of required fields beyond what's necessary, in order to keep the barrier to adopting it low.

I understand this argument for fields that are not available in every API, but this is different here, right?

[juliuste]

@derhuerst ping

[juliuste]

@derhuerst ping