[OASIS Issue Tracker] (ODATA-1118) Clients must not specify select options to the same property path more than once

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Michael Pizzo created ODATA-1118:
------------------------------------

             Summary: Clients must not specify select options to the same property path more than once
                 Key: ODATA-1118
                 URL: https://issues.oasis-open.org/browse/ODATA-1118
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Bug
          Components: Protocol, URL Conventions
    Affects Versions: V4.01_CSD02
         Environment: [Proposed]
            Reporter: Michael Pizzo
             Fix For: V4.01_CSD02


In OData-1105 we introduced an alternate sytnax for selecting a subset of properties of a complex type, as well as specifying other select-options for doing things like filtering and sorting a collection of complex types, but we didn't define any rules around how the new syntax related to the old syntax.  I.e.
Can the client mix the two:
    $select=Address/City,Address($select=State)
Can the client specify the same property in multiple places?
    $select=Addresses/State,Addresses($select=State)
Can the client specify the same property with and without select options?
    $select=Addresses,Addresses($filter=State eq 'Oregon')
Can the client specify different options for the same selectItem?
    $select=Addresses($filter=State eq 'Oregon'),Addresses($filter=State eq 'Washington')
Can the client specify the same property in multiple places?
    $select=Home/Address($select=City),Home($select=Address($select=State)
Can the client mix nav path and select options for the same select item?
    $select=Home/Address($select=City)

With $expand we the simple rule that the same property must not appear in more than one expandItem, which is easy to make because there isn't an alternate path syntax.

The simplest rule would be to say that clients can't mix path syntax and nested $select syntax in the same URL, but that could be overly restrictive.

The next simplest rule would probably be to say that you can't mix path and nested syntax for the same selectItem.  I.e., a $select nested within a select can't specify a path, and a path can't have select options. This would be easy to validate in the ABNF. 

So you could do:
    $select=FullName/FirstName,Address($select=City)
but not:
    $select=Home/Address($select=City)

This would still allow the same property to be expressed with and without select options, which we could add another rule to protect against or just say that any select options are applied.  So:
    $select=Addresses,Addresses($select=City)
would be the same as:
    $select=Addresses($select=City)
Note that we currently don't prohibit the same select item from occurring mutiple times:
    $select=Addresses,Addresses
So we should probably allow it regardless of syntax:
    $select=Addresses/City,Addresses($select=City)

Also, note that this issue is not just restricted to $select. We now have the ability to specify a set of options for the same property, once in $select and once in $expand:
$select=Address($expand=Residents($select=StartsWith(Name,'B')))$expand=Address/Residents($filter=StartsWith(Name,'A'))



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