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-879) Support Arrays of Arrays


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

Michael Pizzo edited comment on ODATA-879 at 2/7/17 2:27 AM:
-------------------------------------------------------------

Assertions:
1) For typical JSON consumers, expanding a primitive value or collection into an object is going to be unexpected and undesired.  We would need a client directive to say that it was okay to change a non-structured value into a structure object.
2) As any way of annotating a primitive is going to be cumbersome, we should minimize the number of cases where a primitive (or array) value has to be annotated.
3) Parallel arrays in payloads are undesireable, particularly if large, because the service may need to make multiple passes through data (if even possible); one to build the annotations and one to build the value array, and clients will need to read both to understand either of them.

Proposal: 
1) Support collections of collections of complex values
2) Since expando-property values are json format-specific, define a format parameter for application/json for expanding all annotated primitives and collections as objects.
3) If not expand option is not specified, omit annotations on collections of primitives and collections. If an annotation is required to understand the payload and can't be written then error. For example, an inner collection would have to be complete (non-paged) if the option for expand-property values was not written.

Variants:
1) Consider supporting arrays of arrays of primitives, but not allowing them to be annotated.
2) Support a syntax for externally annotating non-structural members of an ordered collection by adding a peer to the array property that uses the index as the property name being annotated.  

External annotation Option1:
{
        "foo": [[2, 7], [1, null, 18.34], [7, 2.14, 6, 89]],
        "foo@": {
            "0@count": 2,
            "1@count": 3,
            "1/2@myAnnotation": "Couldn't read handwriting",
            "2@count":4
}

External annotation Option 2:
    {
        "foo": [[2, 7], [1, null, 18.34], [7, 2.14, 6, 89]],
        "foo@": {
            "0@count": 2,
            "1@count": 3,
            "1@" : { "2@myAnnotation": "Couldn't read handwriting"},
            "2@count":4
    }




was (Author: mikep):
Assertions:
1) For typical JSON consumers, expanding a primitive value or collection into an object is going to be unexpected and undesired.  We would need a client directive to say that it was okay to change a non-structured object into a structure object.
2) Any way of annotating a primitive is going to be cumbersome, should minimize the number of cases where a primitive value has to be annotated.
3) Parallel arrays are undesireable, particularly if large, because the service may need to make multiple passes through data (if even possible); one to build the annotations and one to build the value array, and clients will need to read both to understand either of them.

Variants:
1) Consider supporting arrays of arrays of primitives, but not allowing them to be annotated.
2) Support a syntax for externally annotating non-structural members of an ordered collection by adding a peer to the array property that uses the index as the property name being annotated.  

Option1:
{
        "foo": [[2, 7], [1, null, 18.34], [7, 2.14, 6, 89]],
        "foo@": {
            "0@count": 2,
            "1@count": 3,
            "1/2@myAnnotation": "Couldn't read handwriting",
            "2@count":4
}
Option 2:
    {
        "foo": [[2, 7], [1, null, 18.34], [7, 2.14, 6, 89]],
        "foo@": {
            "0@count": 2,
            "1@count": 3,
            "1@" : { "2@myAnnotation": "Couldn't read handwriting"},
            "2@count":4
    }



> Support Arrays of Arrays
> ------------------------
>
>                 Key: ODATA-879
>                 URL: https://issues.oasis-open.org/browse/ODATA-879
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData CSDL, OData JSON Format
>    Affects Versions: V4.0_ERRATA02
>            Reporter: Michael Pizzo
>            Assignee: Michael Pizzo
>             Fix For: V4.01_CSD02
>
>
> There are scenarios where it's convenient to represent something as an array of arrays. In JSON this would look as:
> [["foo1","bar1"],["foo2","bar2"]]
> or
> [[{"foo":"foo1"},{"bar":"bar1"}],[{"foo":"foo2"},{"bar":"bar2"}]]
> Currently services must represent these as arrays of complex types that have array properties. In JSON, the result looks like:
> [{"value":["foo1","bar1"]},{"value":["foo2","bar2"]}]
> or
> [{"value":[{"foo":"foo1"},{"bar":"bar1"}]},{"value":[{"foo":"foo2"},{"bar":"bar2"}]}]
> If we are trying to make JSON representation as close as possible to a custom representation we would need to support the former syntax (without the "value" objects).
> One problem with arrays of arrays in JSON is that we don't have a way to annotate the (array) items within the array. For example, we couldn't add count, nextLink, etc. for the inner arrays..



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