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-1034) Support the notion of a collection of name/value pairs where the type of the value is known


    [ https://issues.oasis-open.org/browse/ODATA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65572#comment-65572 ] 

Michael Pizzo commented on ODATA-1034:
--------------------------------------

Three different annotations we could define, based on use scenarios:

1) <Term Name="PropertyTypeConstraint" Value="Collection(Edm.String)"/>
Applied to a Property to say that property is restricted to a subset of possible derived types (i.e., property of Edm.PrimitiveType must be a string or double, or property of Product must be FoodProduct or ClothingProduct but not HardwareProduct).

=>Note that Edm.PrimitiveType can not be the underlying type for a type definition, so can't apply there.

2) <Term Name="OpenPropertyTypeConstraint" Value="Collection(Edm.String)"/>
Applied to an open entity or open complex type or property of such a type to say that open properties must be of (one of) the specified type(s).
Note: this annotation only applies to open properties; defined properties of the type do not have to conform to this validation.  Thus, the client should not use a typed dictionary as the value for this property.  

3) <Term Name="SomeOtherPropertyTypeConstraint" Value="Collection(Edm.String)"/>
Specify that all properties (declared and open) of the type conform to the specified annotation as a way of telling the client to generate a typed dictionary for the property.

In addition, we could consider adding a "Dictionary" complex type definition to Core that is an open complex type with no properties as a common way of describing a dictionary/property bag.


> Support the notion of a collection of name/value pairs where the type of the value is known
> -------------------------------------------------------------------------------------------
>
>                 Key: ODATA-1034
>                 URL: https://issues.oasis-open.org/browse/ODATA-1034
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: CSDL JSON , CSDL XML, JSON Format, Protocol, URL Conventions
>    Affects Versions: V4.01_CSD01
>            Reporter: Hubert Heijkers
>            Assignee: Hubert Heijkers
>             Fix For: V4.01_CSD02
>
>
> There is currently no easy way (read: without specifying an additional wrapper entity type) of specifying a, what most people would likely refer to as a, dictionary, or a collection of name/value pair, in which I can specify the type of the values!
> So where we would need to do something today like:
>       <EntityType Name="ValueType">
>         <Key>
>           <PropertyRef Name="Key"/>
>         </Key>
>         <Property Name="Key" Type="Edm.String" Nullable="false"/>
>         <Property Name="PropA" ... />
>         ...
>       </EntityType>
>       <EntityType Name="ValueTypeDictionaryWrapper">
>         <Key>
>           <PropertyRef Name="Name"/>
>         </Key>
>         <Property Name="Name" Type="Edm.String" Nullable="false"/>
>         <NavigationProperty Name="Value" Type="ns.ValueType" Nullable="false"/>
>       </EntityType>
>       <AnyStructuredType Name="ValueTypeDictionaryContainer">
>         ...
>         <NavigationProperty Name="Values" Type="Collection(ns.ValueTypeDictionaryWrapper)" Nullable="false"/>
>         ...
>       </AnyStructuredType>
> Note that the wrapper has to be an entity type to be able to use the name (key) to index into the 'dictionary'. This is even a bit weirder if what we are putting in the dictionary is actually complex types that one would want to treat just like a collection of that complex type.
> The payload would look something like this:
>     {
>       "@odata.context": "$metadata#AnyStructuredType(Values(Value))/$entity",
>       ...,
>       "Values": [{
>         "Name": "foo",
>         "Value": {
>           "Key": "38hfgs8",
>           "PropA": "APropA_value",
>           ...
>         },
>         "Name": "bar",
>         "Value": {
>           "Key": "f93d8r3",
>           "PropA": "APropA_value",
>           ...
>         },
>         ...
>       }],
>       ...
>     }
> Needless to say that this JSON representation of an, expanded, payload doesn't look like what a typical JSON consumer would expect and it requiring the wrapped value to be expanded as well..
> So what I'm looking at being able to do is, using the same example, do something like:
>       <EntityType Name="ValueType">
>         <Key>
>           <PropertyRef Name="Key"/>
>         </Key>
>         <Property Name="Key" Type="Edm.String" Nullable="false"/>
>         <Property Name="PropA" ... />
>         ...
>       </EntityType>
>       <AnyStructuredType Name="ValueTypeDictionaryContainer">
>         ...
>         <NavigationProperty Name="Values" Type="Dictionary(ns.ValueTypeDictionaryWrapper)" Nullable="false"/>
>         ...
>       </AnyStructuredType>
> And the resulting JSON payload for requests would look something like:
>     {
>       "@odata.context": "$metadata#AnyStructuredType(Values)/$entity",
>       ...,
>       "Values": {
>         "foo": {
>           "Key": "38hfgs8",
>           "PropA": "APropA_value",
>           ...
>         },
>         "bar": {
>           "Key": "f93d8r3",
>           "PropA": "APropA_value",
>           ...
>         },
>         ...
>       },
>       ...
>     }
> Note the more intuitive typical JSON response and that we don't need to expand the value in the wrapper any longer. 



--
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]