OASIS Open Data Protocol (OData) TCIcon indicating the project type

OASIS Open Data Protocol (OData) TC

Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-1403

Annotation of implicit entity sets

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_CSD03
    • Fix Version/s: V4.0_CSD04
    • Component/s: Data Aggregation, Vocabularies
    • Labels:
      None
    • Environment:

      Proposed

    • Proposal:
      Hide

      Make use of existing specification text in section 14.2.2 Target.

      For vocabulary terms Aggregation.CustomAggregate and Aggregation.ApplySupported, add AppliesTo="Collection" and tag these terms with a new annotation in the Core vocabulary:

      <Term Name="AppliesViaContainer" Type="Core.Tag" DefaultValue="true" Nullable="false" AppliesTo="Term">
 <Annotation Term="Core.Description" String="The target path of an annotation with this term must start with an entity container or the annotation must be embedded within an entity container, entity set or singleton"/>
</Term>

      Deprecate terms Groupable, Aggregatable, complex type NavigationPropertyAggregationCapabilities.

      For compatibility reasons, do not use this technique for annotations in the Capabilities vocabulary.

      Show
      Make use of existing specification text in section 14.2.2 Target . For vocabulary terms  Aggregation.CustomAggregate  and Aggregation.ApplySupported , add  AppliesTo="Collection" and tag these terms with a new annotation in the Core vocabulary: <Term Name= "AppliesViaContainer" Type= "Core.Tag" DefaultValue= "true" Nullable= "false" AppliesTo= "Term" > <Annotation Term= "Core.Description" String= "The target path of an annotation with this term must start with an entity container or the annotation must be embedded within an entity container, entity set or singleton" /> </Term> Deprecate terms Groupable , Aggregatable , complex type NavigationPropertyAggregationCapabilities . For compatibility reasons, do not use this technique for annotations in the Capabilities vocabulary.
    • Resolution:
      Hide

      PR #101.

      Show
      PR #101 .

      Description

      NavigationPropertyBindings are used to assign an entity set to a Path ending in a non-containment navigation property. The assigned entity set can then be the target for annotations like Aggregation.CustomAggregate (see https://issues.oasis-open.org/browse/ODATA-1382).

      Paths ending in a containment navigation property, which implicitly define an entity set, are treated totally different, however. In order to define a custom aggregate on this implicit entity set, the annotation Capabilities.NavigationRestrictions with type Aggregation.NavigationPropertyAggregationCapabilities/CustomAggregates must be used.

      An easier alternative would be to use external targeting with a path that ends in a containment navigation property:
       

      <Annotations Target="namespace.ContainerName/me/Mails">
 <Annotation Term="Aggregation.CustomAggregate" Qualifier="JunkRating" String="Edm.Int32"/>
</Annotations>

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          19 older comments
          Hide
          Permalink
          heiko.theissen Heiko Theissen added a comment - - edited

          "Core" navigation property restrictions could be represented by the Capabilities.NavigationPropertyRestriction type, but all non-core ones (whether from the Aggregation vocabulary or some other, perhaps future, vocabulary) cannot: Because if every vocabulary introduced its own sub-type (like Aggregation.NavigationPropertyAggregationCapabilities has done), a given Capabilities.NavigationRestrictions/RestrictedProperties annotation could choose only one of these subtypes, so it could not express both a custom aggregate and a restriction from a future vocabulary on the same NavigationProperty. (No multiple inheritance.)

          On the other hand, it is infeasible if every vocabulary had to insert its restrictions into the Capabilities.NavigationPropertyRestriction type.

          Show
          heiko.theissen Heiko Theissen added a comment - - edited "Core" navigation property restrictions could be represented by the Capabilities.NavigationPropertyRestriction type, but all non-core ones (whether from the Aggregation vocabulary or some other, perhaps future, vocabulary) cannot: Because if every vocabulary introduced its own sub-type (like Aggregation.NavigationPropertyAggregationCapabilities has done), a given Capabilities.NavigationRestrictions/RestrictedProperties annotation could choose only one of these subtypes, so it could not express both a custom aggregate and a restriction from a future vocabulary on the same NavigationProperty . (No multiple inheritance.) On the other hand, it is infeasible if every vocabulary had to insert its restrictions into the Capabilities.NavigationPropertyRestriction type.
          Hide
          Permalink
          handl Ralf Handl added a comment -

          Good point!

          Maybe we should add mixins in V5 �

          Show
          handl Ralf Handl added a comment - Good point! Maybe we should add mixins in V5 �
          Hide
          Permalink
          heiko.theissen Heiko Theissen added a comment - - edited

          An annotation like

          /namespace.ContainerName/me/Mails@Aggregation.CustomAggregate#JunkRating

          can be addressed via an Edm.AnnotationPath, for example in a bar chart annotation if the aggregated value shall be represented as the height of a bar.

          By contrast, the Edm.PropertyPath

          /namespace.ContainerName/me/@Capabilities.NavigationRestrictions
/RestrictedProperties/1/CustomAggregates/0

          is much more cumbersome (especially the index segments) and, not being an Edm.AnnotationPath, cannot be governed by Validation.AllowedTerms.

          Show
          heiko.theissen Heiko Theissen added a comment - - edited An annotation like /namespace.ContainerName/me/Mails@Aggregation.CustomAggregate#JunkRating can be addressed via an Edm.AnnotationPath , for example in a bar chart annotation if the aggregated value shall be represented as the height of a bar. By contrast, the Edm.PropertyPath /namespace.ContainerName/me/@Capabilities.NavigationRestrictions /RestrictedProperties/1/CustomAggregates/0 is much more cumbersome (especially the index segments) and, not being an Edm.AnnotationPath , cannot be governed by Validation.AllowedTerms .
          Hide
          Permalink
          mikep Michael Pizzo (Inactive) added a comment -

          Note: there are solutions to having multiple vocabularies extend NavigationRestrictions (for example, through dynamic properties).

          Show
          mikep Michael Pizzo (Inactive) added a comment - Note: there are solutions to having multiple vocabularies extend NavigationRestrictions (for example, through dynamic properties).
          Hide
          Permalink
          handl Ralf Handl added a comment -

          2021-03-18

          Show
          handl Ralf Handl added a comment - 2021-03-18

            People

            • Assignee:
              Unassigned
              Reporter:
              heiko.theissen Heiko Theissen
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: