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-584) Change the name of the "AllPropertiesSupported" property of the "ApplySupported" term to something more meaningful

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

Ralf Handl updated ODATA-584:

    Proposal: Rename "AllPropertiesSupported" to "PropertyRestrictions" with a default value of false.  (was: Rename "AllPropertiesSupported" to "PropertyRestrictions" which is false if not present, and has a default value of true if specified.)

> Change the name of the "AllPropertiesSupported" property of the "ApplySupported" term to something more meaningful
> ------------------------------------------------------------------------------------------------------------------
>                 Key: ODATA-584
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-584
>             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
>            Priority: Minor
>             Fix For: V4.0_CSD02
> We had long debates on how to handle the case where a service supported grouping and aggregation on all properties versus having to annotate each property as groupable and/or annotatable.
> We initially said that the service would annotate each property as being groupable and/or aggregatable, and the absence of any such annotation, in the presence of an ApplySupported, meant that there were no restrictions on which property could be used in groupby or and aggregate clause. The problem with this was it required looking at all properties to see if any were annotated in order to determine if absence of an annotation on a single property implied it was not groupable/aggregatable, or that there were no such restrictions.
> So we added a single property to the ApplySupported aggregation term that a client could check to see if there were any such restrictions. We called this property "AllPropertiesSupported", which is really not very intuitive or meaningful.
> There are a couple of options for improving this:
> 1) We could have two properties, "AllPropertiesGroupable" and "AllPropertiesAggregatable", which would allow us to separately specify whether there are restrictions on grouping versus aggregation.
> 2) If we don't think there is an interesting scenario for a service having different rules for all properties being groupable versus all properties being aggregatable, we could name the property something like "PropertyRestrictions" which would be true if you can't group/aggregate individual properties, and defaults to false meaning there are no restrictions around properties. This is also kinda nice in that it can have a default value of true, so you can use it as a tag for the case where restrictions exist, or just omit it if restrictions don't exist).

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]