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: [OASIS Issue Tracker] (ODATA-811) Define propagation and overriding of annotations


     [ https://issues.oasis-open.org/browse/ODATA-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-811:
-----------------------------

        Summary: Define propagation and overriding of annotations  (was: Define propagation and (partial) overriding of annotations)
    Environment: Proposed
       Proposal: 
Propagation along inheritance hierarchies:
- Annotations on structured types and their properties also propagate down from the base type to the derived types
- Annotations can be overridden at the derived type or its properties with replace (PUT) semantics for all types of annotations: primitive, structured, collection-valued.

Propagation along "uses" dependencies
- It is up to the definition of the term to specify whether and how annotations with this term propagate to places where the annotated model element is used, and whether they can be overridden. E.g. a "Label" annotation for a UI can propagate from a type definition to all properties using that type, and may be overridden it in some cases with a more specific label, whereas an annotation marking a property as containing a phone number will propagate but may not be overridden.

  was:
Propagation along inheritance hierarchies:
- Annotations on structured types and their properties also propagate down from the base type to the derived types
- Annotations can be overridden at the derived type or its properties with replace (PUT) semantics for all types of annotations: primitive, structured, collection-valued.

Propagation along "uses" dependencies
- If an annotation is applied to a model element that "uses" another model element and is also applied to the "used" model element (e.g. a property and the type of the property, an entity set and its declared entity type), the annotation defined directly at a model element overrides the same annotation defined at the used/referenced model element with replace (PUT) semantics for all types of annotations: primitive, structured, collection-valued.

Consumers (client libraries) interested in annotations for a model element have to inspect referenced model constructs, and for structured types the base type(s) to determine the effective annotation value for this model element.

If annotations reference other annotations via the AnnotationPath construct, the search for the effective annotation value restarts at the model element the consumer is interested in. Example: base type has annotation that references other annotation. This other annotation is overridden on a derived type. The annotation consumer interested in the derived type has to use the referenced annotation value on the derived type.


> Define propagation and overriding of annotations
> ------------------------------------------------
>
>                 Key: ODATA-811
>                 URL: https://issues.oasis-open.org/browse/ODATA-811
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL, Vocabularies
>    Affects Versions: V4.0_ERRATA02
>         Environment: Proposed
>            Reporter: Ralf Handl
>            Assignee: Ralf Handl
>              Labels: Clarification
>             Fix For: V4.01_WD01
>
>
> We regularly face situations where we want to "propagate" annotations on a model element to all places where this model element is used/referenced, e.g. annotate an entity type and then have that annotation apply to all entity sets, or annotate a type definition and have that annotation apply to all properties or action parameters of that type.
> An explicit annotation on one of the usage/reference points would then overrule/modify the annotation on the used/referenced construct.
> The current specification text seems to implicitly assume this behavior, but doesn't explicitly state rules on
> - where do annotations propagate to?
> - how are structured annotations modified? PATCH semantics if only partially specified?



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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