OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Terminology for "owned data"


Comments inline.

[GME]

 

From: odata@lists.oasis-open.org <odata@lists.oasis-open.org> On Behalf Of Handl, Ralf
Sent: Thursday, April 29, 2021 4:30 AM
To: Christof Sprenger; Ericson, George; Michael Pizzo; odata@lists.oasis-open.org
Subject: [odata] RE: Terminology for "owned data"

 

[EXTERNAL EMAIL]

The problem I see here is that the three use cases you mentioned all have different distinctions:

 

  1. when deep insert works
    1. whenever the service or underlying business logic wants it to work: deep insert also works along non-containment navigations, i.e. create a new customer and âdeep-createâ the customerâs first order, despite both having own top-level entity sets and the navigation property from Customer to Order is non-contained

[GME] Yes, navigation and containment are not related. 

 

Q: Is there an issue for insertions using navigation properties that are not composite (ContainsTarget=True) in the case where the NavigationPropertyBinding is not explicit?

 

  1. when an aggregation function can be used
    1. canât answer that at the current fluent state of the aggregation discussion 😊
  2. when a context url is a path vs a type
    1. Itâs a path if there is a sequence of containment navigation or non-containment navigation with a unambiguous navigation property bindings, and a type in all other cases, especially in MEST cases â Multiple Entity Sets per Type

 

[GME] I prefer not to characterize a context url as a path or a type.  It is always just an address to something.

My thoughts:

The protocol spec defines the  context URL as:  "the canonical metadata document URL and a fragment identifying the relevant portion of the metadata document." 

That portion should always reference a typed element. The metadata document portion for a typed element includes a reference to element's type.

  • If the typed element is Singleton or EntitySet or a Navigation Property that is ContainsTarget=True, then the related items are contained by the typed element.
  • If the typed element is a Navigation Property that is not ContainsTarget=True, then the related items are not contained by the typed element.
    • In that case, a NavigationPropertyBinding defines containment and if not present, then containment is implementation specific.

 

 

I donât see one new âterminology termâ that can explain all three of them, we probably need at least three new pieces of terminology.

 

From: Christof Sprenger <chrispre@microsoft.com>
Sent: Wednesday, 28 April 2021 20:21
To: George.Ericson@dell.com; Michael Pizzo <mikep@microsoft.com>; Handl, Ralf <ralf.handl@sap.com>; odata@lists.oasis-open.org
Subject: RE: Terminology for "owned data"

 

Thanks George,

 

Yes, definitely helpful.

 

My goal with the discussion I want to have is to actually agree on something like what you wrote about composition.

But more importantly to give it a name so that we donât always have to explain when some feature/operation/capability  applies (or can be applied) and when not (e.g. when deep insert works, when an aggregation function can be used, when a context url is a path vs a type, â ).

 

Christof

 

From: Ericson, George <George.Ericson@dell.com>
Sent: Wednesday, April 28, 2021 11:07
To: Christof Sprenger <chrispre@microsoft.com>; Michael Pizzo <mikep@microsoft.com>; ralf.handl@sap.com; odata@lists.oasis-open.org
Subject: [EXTERNAL] RE: Terminology for "owned data"

 

Some thoughts on this topic.

 

  1. I consider OData containment as semantically the same as UML composition.

UML defines AggregationKind='composite' as an indication that a Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects.

  1. By the UML definition, all OData Properties, EntitySets, Singletons and NavigationProperties with ContainsTarget=True are composite objects.
  2. In OData, a contained value is aggregated by an OData composite object. (Entities are a special kind of value.)
  3. EntitySets, Singletons, and NavigationProperties have values that are Entities.
  4. URLs are always only addresses.  Composite objects own their component objects.   So, an URL can address a composite object.
  5. In response to a GET, a By-Value and By-Reference representation of an Entity value is orthogonal to composition (or ownership).

 

Hope some of that is helpful,

George

 

From: odata@lists.oasis-open.org <odata@lists.oasis-open.org> On Behalf Of Christof Sprenger
Sent: Wednesday, April 28, 2021 12:47 PM
To: Michael Pizzo; ralf.handl@sap.com; odata@lists.oasis-open.org
Subject: [odata] Terminology for "owned data"

 

[EXTERNAL EMAIL]

Hello,

 

Wasnât sure how to frame the following as an Issue, so I am starting with an email.

 

In recent TC meetings and in my day job we often need to distinguish between different paths/URLS and if they are returning something contained or not. We had the discussion a few times during the review of aggregation, and I had to go into it internally to discuss deep inserts.

 

The closest I could find is in 10.2 Collection of Entities [docs.oasis-open.org] [nam06.safelinks.protection.outlook.com]. There is the distinction between contained Entities and âothersâ. But a) the description for âothersâ is quite lengthy and it is not clear that this covers all the other cases b) it is the first time in that document that the phrase ââ entities are containedâ is actually used, c) this only addresses collection of Entities and sections 10.3-10.15 have to essentially make similar statements or refer to 10.2.

 

4.3.2 Canonical URL for Contained Entities [docs.oasis-open.org] [nam06.safelinks.protection.outlook.com] also mentions quote: â[â] contained entities (i.e. related via a containment navigation property [â]â .

It feels weird that the phrase âcontained entitiesâ is previously not mentioned and quickly defined in the spot (in parenthesis, without mentioning a path of containment navigation property)

 


Would it not be helpful to introduce terminology that clearly categorize URLs into

  • Response contains data that is âownedâ by this URL  (e.g. entity-set, a path of only containment navigation properties, â )
    • Owned in the sense that this is where it is stored and all create-update-delete operations âgoâ
  • Response contains data that is âreferencedâ  (e.g. a function, multiple navigation property bindings, â)

 

I hope that such a definition would help with describing and discussing many problems but I am not really able (as you can see above) to get to a crisp definition.

Have I overlooked that kind of definition ? If not, can/should this be a topic for the TC?

 

Christof

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]