OData TC meeting #88 Thursday Jan 08, 2015

Acting chair: Ram

Chat transcript from room: odatatc
2015-01-08 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)
        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 December 11, 2014 TC meeting:

Meeting#87 on 2015-DEC-11

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 January 08, 2015


5. Issues for V4.0_ERRATA03 in Applied state

Ralf: Moving this agenda item to next week to give TC members more time to check issues

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

6.1 OData Protocol

6.1.1 ODATA-479 "Allow Content-ID referencing in request bodies for inserting links to newly created entities"


PUT $2/SingleValuedNavigationProperty
"@odata.context": "http://host/service/$metadata#$ref",
"@odata.id": "$1"

Ralf: ODATA-479 is OPEN

Mike: not sure if we can do this in an errata. Might conflict with id schemes that use a leading $ sign. Investigation needed. If this is done as an extension, we'll need a capability annotation that advertises this feature.

6.1.2 ODATA-761 "Invoking an Action: Location header for 201 Created responses"

Mike: check HTTP rules whether 201 mandates/suggests a Location header

Adapted proposal:

Create and return single entity: 201 Created with Location header
Create and return multiple entities: 200 Ok, no Location header
Any other return type: 200 Ok
No return type: 204 No Content
If the client requests no results with the return preference, the rules of section apply.

Ralf: Create entity/entities and return collection of entities: 200 Ok, no Location header

Mike: suggested wording: "Create and return an entity collection: 200 Ok, no Location header"

Mike: suggests not mentioning the "return collection of entities" case


6.3.2. 201 Created

The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location
field is received, by the effective request URI.

Martin: http://tools.ietf.org/html/rfc7231#section-6.3.2


7.1.2. Location

The "Location" header field is used in some responses to refer to a
specific resource in relation to the response. The type of
relationship is defined by the combination of request method and
status code semantics.

Location = URI-reference

The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI
([RFC3986], Section 5).

For 201 (Created) responses, the Location value refers to the primary
resource created by the request.

Ralf: https://tools.ietf.org/html/rfc7231#section-7.1.2

Ralf: For create/return single entity refer to rules for creating an entity: location header is MUST, return code either 201 or 204

Ralf: ODATA-761 is open

Ralf: Preference return=representation and return=minimal

Mike: Actions that create and return a single entity follow the rules for entity creation - must return a location header, should return 201 created unless the return-minimal preference has been specified, in which case the service may return 204 and no content, but still include the location header.

Hubert: I move to resolve ODATA-761 as per the newly stated proposal. Martin seconds

ODATA-761 is resolved as proposed

6.2 OData JSON Format

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


"enumValue":42 ???

Ralf: Current proposal:
Values of type enumValue are represented as JSON strings. The preferred representation is the enumerationMember, defined in [OData-ABNF], where available.

Mike: Current proposal:

Add example for numeric value to section 7.1

Rephrase sentence to

Values of type enumValue are represented as JSON strings.
The preferred representation is the enumerationMember, defined in
[OData-ABNF], where available.

Strengthen wording throughout that the numeric value should only be used if there is no string equivalent, both in payloads and in urls.

Ralf: ODATA-754 is open


Mike: I move to resolve ODATA-754 as proposed. Hubert seconds

ODATA-754 is resolved as proposed

6.2.2 ODATA-762 "Section 8.5: clarify that @odata.bind:null is valid for updating of 0..1 navigation properties"

Ralf: ODATA-762 is open

Martin: I move to resolve ODATA-762 as proposed. Mike seconds

ODATA-762 is resolved as proposed

6.3 OData CSDL

6.3.1 ODATA-734 "Unicode Facet is inadequate"

John: Note the discussion on XML and ATOM on ASCII characters < 30 or special characters in OData

Mike: Proposal from ODATA-734:

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

Services can return a 500 error if they receive a value that cannot be persisted.

Matt: I move to resolve ODATA-734 asproposed. Mike seconds

ODATA-734 is resolved as proposed

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

Ramesh: Is there a XML Schema for the XML representation?

Mike: Yes.

Ralf: Hand-crafted JSON:


Ralf: JSON-Schema:


Mike: One last comment; since JSON Schema isn't a standard yet, we may be able to address some of the issues (like nullability) in JSON Schema, rather than rolling our own.

8. Next meeting

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


9. Acknowledgement section

Ralf to open a jira issue.

10. AOB


Meeting adjourned at 10:00 PT