OData TC meeting #87 Thursday Dec 11, 2014

Acting chair: Ram

Chat transcript from room: odatatc
2014-12-11 0800-1000 PDT

1. Roll call

1.1 Members present

        Edmond Bourne (BlackBerry)
        Gerald Krause (SAP AG)
        Hubert Heijkers (IBM)
        Jason Fam (IBM)
        John Willson (Individual)
        Ken Baclawski (Northeastern University)
        Mark Biamonte (Progress Software)
        Martin Zurmuehl (SAP AG)
        Matthew Borges (SAP AG) a.k.a. Matt 
        Michael Pizzo (Microsoft) a.k.a. Mike
        Ralf Handl (SAP AG)
        Ram Jeyaraman (Microsoft)
        Ramesh Reddy (Red Hat)
        Stefan Drees (Individual)
        Susan Malaika (IBM)
        Ted Jones (Red Hat)

Quorum achieved. Details cf. normative attendance sheet for this meeting.

Notes taken by all and subsequently edited for readability by Stefan.

2. Approve agenda

Agenda approved as published.

3. Approve minutes from previous meeting(s)

3.1 Minutes from November 20, 2014 TC meeting:

Meeting#86 on 2014-NOV-20

Minutes approved unchanged as published

4. Review action items

URL=Action item list at https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php

4.1 Action items due by December 11, 2014

None

5. Process issues (for V4.0_ERRATA03 in New or Open state)

5.1 OData CSDL

5.1.1 ODATA-755 "Construction rule for canonical URL is incomplete"

ODATA-755 is open

Ralf:
GET /collection/keyvalue
GET /collection/keyvalue1/keyvalue2

Ralf: Key parts may have hierarchical order which would be destroyed by lexicographical ordering

Stefan: Most path orderings should not depend on lexicographical instance ordering but instead adhere to some stable ordering (eg. given by schema).

Ralf: Needs to be taken into account when designing JSON CSDL: use an array for defining the key to preserve order

Mike: revised proposal:
For single-part keys the canonical key predicate does not contain the key property name.

For multi-part keys the canonical key predicate lists the key properties in the order they appear in the CSDL.

Mike: I move we resolve ODATA-755 according to the revised proposal. Martin seconds

ODATA-755 is resolved as proposed by Mike

Motion passes, no objections

5.1.2 ODATA-734 "Unicode Facet is inadequate"

Ralf: ODATA-734 is open

Ralf: Need to define how services should handle codepages between ASCII and Unicode

Ralf: Servers supporting more than ASCII should advertise Unicode="true" to tell clients that it will send more than ASCII

Ralf: Servers should respond with a meaningful error in the 5xx range if the client sends characters that the server cannot store

Mike: Proposal: Services return TRUE if strings support characters outside of the ASCII character set and FALSE if only characters within the ASCII set are supported.

Hubert: I move to resolve ODATA-734 according to the revised proposal. Matt seconds

ODATA-734 is resolved as proposed by Mike

5.2 OData JSON Format

5.2.1 ODATA-754 "Clarify that numeric enum values are serialized as strings"

ODATA-754 is open

Ralf: EnumMember names have to start with a letter, otherwise member names and member values couldn't be distinguished
Metadata:

<EnumMember Name="8" Value="16"/>

<EnumMember Name="16" Value="32"/>

Atom Request:

<d:enumvalue>16</d:enumvalue>

would be ambiguous: first member by value or second member by name.

JSON would allow distinguishing this using the JSON type (string vs. number):

"enumvalue":"16"
"enumvalue":16

ABNF says:

enum = qualifiedEnumTypeName SQUOTE enumValue SQUOTE
enumValue = singleEnumValue *( COMMA singleEnumValue )
singleEnumValue = enumerationMember / enumMemberValue
enumMemberValue = int64Value

blue
blue,yellow
8,16
8
16

5.2.2 ODATA-756 "Clarify when odata.metadataEtag will be returned"

ODATA-756 is open

Martin: An ETag header MAY also be returned on a metadata document request or service document request to allow the client subsequently to make a conditional request for the metadata or service document. Clients can also compare the value of the ETag header returned from a metadata document request to the metadata ETag returned in a response in order to verify the version of the metadata used to generate that response.

Martin: This is from 8.3.1 Header ETag

Mike: Proposal from issue (changing MUST to SHOULD):If an ETag is returned when requesting the metadata document, then the service SHOULD set the odata.metadataEtag annotation to the metadata document's ETag in all responses when using odata.metadata=minimal or full. If no ETag is returned when requesting the metadata document, then the service SHOULD NOT set the odata.metadataEtag annotation in any responses.

Martin: ... in protocol

Martin: I move to resolve ODATA-756 according to the revised proposal. Matt seconds.

ODATA-756 is resolved as proposed by Mike

5.3 OData URL Conventions

5.3.1 ODATA-758 "Example 81: wrong parameter style"

Ralf: http://host/service/ProductsByColor?colors=["red","green"]

Ralf: http://host/service/ProductsByColors(colors=@c)?@c=["red","green"]

ODATA-758 is open

Martin: I move to resolve ODATA-758 according to the proposal. Mike seconds.

ODATA-758 is resolved as proposed

6. OData JSON Format for Common Schema Definition Language (CSDL)

All walk through the current document

Current draft: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/54598/odata-json-csdl-v4.0-wd01-2014-11-21.docx

Snippets from discussion:
"Concurrency":{"$ref":"http://docs.oasis-open.org/odata/odata-json-csdl/v4.0/edm.json#/definitions/Edm.Int32"},
"Concurrency":{"$ref":"#/definitions/Edm.Int32"},
"Edm.Int32":{"$ref":"http://docs.oasis-open.org/odata/odata-json-csdl/v4.0/edm.json#/definitions/Edm.Int32"},

"org.example.Pattern":{
      "anyOf":[
        {
          "enum":[
            "Plain",
            "0",
            "Red",
            "1",
            "Blue",
            "2",
            "Yellow",
            "4",
            "Solid",
            "8",
            "Striped",
            "16",
            "SolidRed",
            "9",
            "SolidBlue",
            "10",
            "SolidYellow",
            "12",
            "RedBlueStriped",
            "19",
            "RedYellowStriped",
            "21",
            "BlueYellowStriped",
            "22"
          ],
        },
        {
          "type":"string",
          "pattern":"^(Plain|Red|Blue|Yellow|Solid|Striped|SolidRed|SolidBlue|SolidYellow|RedBlueStriped|RedYellowStriped|BlueYellowStriped|[1-9][0-9]*)(,(Plain|Red|Blue|Yellow|Solid|Striped|SolidRed|SolidBlue|SolidYellow|RedBlueStriped|RedYellowStriped|BlueYellowStriped|[1-9][0-9]*))*$"
        }
      ]
    }

"org.example.ShippingMethod":{
      "enum":[
        "FirstClass",
        "0",
        "TwoDay",
        "1",
        "Overnight",
        "2"
      ],
      "FirstClass@Core.Description":"Shipped with highest priority",
      "TwoDay@Core.Description":"Shipped within two days",
      "Overnight@Core.Description":"Shipped overnight"
      "@Core.Description":"Method of shipping"
    }
"Model1.Text50":{
      "type":"string",
      "maxLength":50
    },
    "Model1.VariableDecimal":{
      "type":"number",
      "@Core.Description":"A type definition"
    },
    "Model1.ExactTimestamp":{
      "$ref":
      "http://docs.oasis-open.org/odata/odata-json-csdl/v4.0/edm.json#/definitions/Edm.DateTimeOffset"
    }
{
  "$schema":"http://docs.oasis-open.org/odata/odata-json-csdl/v4.0/edm.json#",
  "definitions": ,
  "schemas": ,
  "references":
}

Example 39: a schema for validating messages containing a single Product entity
{
  "$schema":"http://json-schema.org/draft-04/schema#",
  "allOf": [{
      "$ref": "csdl-16.1.json#/definitions/ODataDemo.Product"
    }
  ]
}

4.2.4 Annotations
...

7. Next meeting

Suggested is 2015-JAN-08 8:00-10:00am PT

Agreed

8. AOB

None.

Meeting adjourned at 10:00 PT