[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: instance annotations
|
Yes, I saw @Core.Computed, but it is too limited. Derivation constraints are well defined by OMG in UML and in OCL. In the example, I have no disagreement with having Company.currency computed by the implementation. On the other hand, Product.currency is dependent on Company.currency, so the derivation is simple
to model. I suppose, there might be a case where Product.currency does not have a well-defined derivation. In that case having information about how it was computed could be useful, but noteâ the derivation
can be arbitrarily complex. George From: Handl, Ralf <ralf.handl@sap.com> [EXTERNAL EMAIL] Properties carrying derived/computed values can be annotated in $metadata with
@Core.Computed. These properties are implicitly read-only, and we donât tell the client how their values are computed by the service. Even in the modeling languages underpinning our OData APIs we have
virtual elements that end up as computed properties in OData APIs, and the modeler doesnât tell how the values of these elements will come into existence. Some piece of application logic will
conjure up those values eventually. Even if we could tell the client how to derive some values: what would we expect the client to do with this derivation rule? From: Ericson, George <George.Ericson@dell.com>
Oops, correction. Product: company: Company amount: Decimal currency: String = company->currency // derived value Company: currency: String From: odata@lists.oasis-open.org <odata@lists.oasis-open.org>
On Behalf Of Ericson, George [EXTERNAL EMAIL] Heiko, Thanks for this explanation. I would prefer a more explicit solution that uses derivation. I didnât find a Term that would express derivation.
Product: company: Company amount: Decimal currency: String = company->company // derived value Company: currency: String From:
odata@lists.oasis-open.org <odata@lists.oasis-open.org>
On Behalf Of Ericson, George Ralf, Just curiousâ. What is SAPâs rational for applying a Term to an instance (i.e. a realization of a model element), as opposed to adding a property/method to the model element? Thanks, From: Handl, Ralf <ralf.handl@sap.com>
[EXTERNAL EMAIL] We use the tagging term Common.IsInstanceAnnotation to mark terms that are intended for instance annotations, see
https://github.com/SAP/odata-vocabularies/blob/master/vocabularies/Common.md#IsInstanceAnnotation PS:
@Michael Pizzo,
@Christof Sprenger: I did not receive your mails in this thread, only Georgeâs response to your mails.
From:
odata@lists.oasis-open.org <odata@lists.oasis-open.org>
On Behalf Of Ericson, George There are examples where an annotation is meant to be applied to an instance and not the model that describes the instance. For example in the Redfish vocabulary there is this:
<Term Name="Settings" Type="Settings.Settings">
<Annotation Term="OData.Description" String="The link to the settings resource that represents the settings to apply to this resource."/>
</Term> As I understand it, this Term could have been alternatively defined as a âSettingsâ property of the model that it is applied to.
My preference would be to use instance annotations only as a way to pass information about the underlying Model that an instance is realized from. If we want to dig deeper, we could ask a representative of the
Redfish team to provide more rational. Thanks, George From:
odata@lists.oasis-open.org <odata@lists.oasis-open.org>
On Behalf Of Michael Pizzo [EXTERNAL EMAIL] We don't currently have a way to specify that an annotation term is intended for use as an instance annotation â to my recollection, it has never come up. How would this information be useful to the client? Is it just a matter of documenting how the term is intended to be used, or is it required at runtime in order to invoke some type of logic? If it's part of documenting the usage, then we generally try to convey that in the description â having a machine-readable way to determine if a term is intended as an instance annotation is useful if code needs
to determine applicability. For comparison, the AppliesTo attribute for metadata annotations is intended to help schema designers know where they can put what terms (i.e., you can have a drop-down of terms that are applicable to a particular
model element without having to understand the semantics of the term.) AppliesTo is *not* intended to be restrictive (i.e., clients should not throw an error if a term is used somewhere that is not called out in AppliesTo). Similarly, clients should never error due to an unexpected/unknown instance annotation, so I wouldn't add a way to distinguish a term as intended for an instance annotation in order to add client validation. From:
odata@lists.oasis-open.org <odata@lists.oasis-open.org>
On Behalf Of Christof Sprenger Hello, I would have expected to find something in the annotation term applicability table that allows me to specify that an annotation is intended as an instance annotation.
OData
Common Schema Definition Language (CSDL) XML Representation Version 4.01 (oasis-open.org) Am I misunderstanding something how a term is supposed to be defined that can be used as an
instance annotation? Or is this a gap in the standard? Christof |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]