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] Updated: (ODATA-582) Simplify custom aggregate term


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

Ralf Handl updated ODATA-582:
-----------------------------

    Resolution: https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/vocabularies/Org.OData.Aggregation.V1.xml?rev=543

> Simplify custom aggregate term
> ------------------------------
>
>                 Key: ODATA-582
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-582
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Extension for Data Aggregation 
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.0_CSD02
>
>
> In the current draft we have introduced an annotation term for defining a custom aggregate that can be applied to either an entity type or an entity container.  The term's type is a complex type with a single property named "Type" which is the type returned by the custom aggregate.
> Because the type of the term is a complex type, rather than a simple type, application of the term requires a record constructor as in:
> <Annotation Term="Aggregation.CustomAggregate" Qualifier="Forecast">
>   <Record>
>     <PropertyValue Property="Type" String="Edm.Decimal"/>
>   </Record>
> </Annotation>
> However, since we have only one property defined for the term we can make the term be of that type (string), rather than a complex type having a single property of that type. This would allow a much more concise application as:
> <Annotation Term="Aggregation.CustomAggregate" Qualifier="Forecast" String="Edm.Decimal"/>
> The drawbacks to this approach are:
> 1) It would be harder to add additional properties to a custom aggregate in the future. However, the most common properties to want to add would be facets, and we could use a TypeDefinition for that. For other extensions, we could use the common metadata extension mechanism of annotating the annotation.
> 2) It is slightly less intuitive what the single property represents. In the old format, you had the name of the property ("Type") to give you a hint what the string represented. In the new syntax you have to know that the string property that is the value of the custom aggregate is the type. We could rename the term something that would indicate that the string property represented the type of the custom aggregate (i.e., "CustomAggregateType"), but that would probably be even more confusing as the term really does define the aggregate (whose name is specified through the qualifier attribute) and not just the type of something being annotated.
> Still, the simplicity of expression seems to outweigh either of these drawbacks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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