Open APIs

I'm not entirely sure why they decided to change the attribute name, but here's a guess:

It was likely to bring more consistency and reduce subjective choices in naming attributes.

The entity name itself should provide enough context to indicate what is created. For example, entityName -> xxxxDate : ProductOrder -> creationDate, completionDate.

One advantage is having a single, unified definition that works across all entities and APIs, making things more streamlined.

Another benefit comes when applying polymorphism. The term "creationDate" is neutral, it simply indicates when the entity was created, making it adaptable for any @Type. On the other hand, "orderDate" is more specific, tied to the creation of an order, and therefore less flexible for reuse.

for order, polyphormism is not going to be a big advantage, but for party, where you have many types of party, you want a generic date field, not customer, prospect, partner.. something date.

PS:

I can just picture the API owners at TMForum, sitting up on Mount Olympus like Greek Gods, watching us, mere mortals, struggle to figure out how to use the divine tools and assets they've bestowed upon us.

LOL... thanks Matthieu for the Friday humour.

The only concern with the creationDate for the ProductOrder entity is that the draft mode is still supported, only the removal of the SubmitProductOrder TASK resource has occurred.  I am presuming that the creation date would be the date that the entity was created, e.g. in draft state.  This means that when the order is transitioned to acknowledged, i.e. when the order is placed, this (order) date is no longer available.

I'm not entirely sure why they decided to change the attribute name, but here's a guess:

It was likely to bring more consistency and reduce subjective choices in naming attributes.

The entity name itself should provide enough context to indicate what is created. For example, entityName -> xxxxDate : ProductOrder -> creationDate, completionDate.

One advantage is having a single, unified definition that works across all entities and APIs, making things more streamlined.

Another benefit comes when applying polymorphism. The term "creationDate" is neutral, it simply indicates when the entity was created, making it adaptable for any @Type. On the other hand, "orderDate" is more specific, tied to the creation of an order, and therefore less flexible for reuse.

for order, polyphormism is not going to be a big advantage, but for party, where you have many types of party, you want a generic date field, not customer, prospect, partner.. something date.

PS:

I can just picture the API owners at TMForum, sitting up on Mount Olympus like Greek Gods, watching us, mere mortals, struggle to figure out how to use the divine tools and assets they've bestowed upon us.

Yes, it was meant as humour, but it also highlights a concern: it feels as though TMF and TMF API owners aren't engaging with this community. It's discouraging to see an organisation create a product, such as the API, without offering sufficient support. We used to prioritise TMF APIs when acquiring software, but that's no longer the case. Personally, I'm considering stepping back from the community, as it has become less rewarding and impactful.

LOL... thanks Matthieu for the Friday humour.

The only concern with the creationDate for the ProductOrder entity is that the draft mode is still supported, only the removal of the SubmitProductOrder TASK resource has occurred.  I am presuming that the creation date would be the date that the entity was created, e.g. in draft state.  This means that when the order is transitioned to acknowledged, i.e. when the order is placed, this (order) date is no longer available.

I'm not entirely sure why they decided to change the attribute name, but here's a guess:

It was likely to bring more consistency and reduce subjective choices in naming attributes.

The entity name itself should provide enough context to indicate what is created. For example, entityName -> xxxxDate : ProductOrder -> creationDate, completionDate.

One advantage is having a single, unified definition that works across all entities and APIs, making things more streamlined.

Another benefit comes when applying polymorphism. The term "creationDate" is neutral, it simply indicates when the entity was created, making it adaptable for any @Type. On the other hand, "orderDate" is more specific, tied to the creation of an order, and therefore less flexible for reuse.

for order, polyphormism is not going to be a big advantage, but for party, where you have many types of party, you want a generic date field, not customer, prospect, partner.. something date.

PS:

I can just picture the API owners at TMForum, sitting up on Mount Olympus like Greek Gods, watching us, mere mortals, struggle to figure out how to use the divine tools and assets they've bestowed upon us.