OData TC meeting #93 Thursday Mar 19, 2015

Acting chair: Ralf

Chat transcript from room: odatatc
2015-03-19 0800-1000 PDT

1. Roll call

1.1 Members present

        Brent Gross (IBM)
        Gerald Krause (SAP AG)
        Jason Fam (IBM)
        John Willson (Individual)
        Ken Baclawski (Northeastern University)
        Martin Zurmuehl (SAP AG)
        Michael Pizzo (Microsoft) a.k.a. Mike
        Ralf Handl (SAP AG)
        Stefan Hagen (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 March 12, 2015 TC meeting:

Meeting#92 on 2015-MAR-12

Minutes approved unchanged as published

3.2 Minutes from February 26, 2015 TC meeting:

Minutes from February 26, 2015 TC meeting (reworked)

Minutes approved 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 March 19, 2015

4.1.1 Follow up with JSON-Schema on use for modeling

Established contact

Ralf: Meeting set up to discuss our issues

Ralf: Positive initial feedback on our issues

John: http://json-schema.org/ could you share some of the discussion on a blog?

Ralf: Strong suggestion on not using anything other than JSON Schema

John: Susan? https://groups.google.com/forum/#!forum/json-schema

Susan: The I-JSON Message Format draft-ietf-json-i-json-06
https://tools.ietf.org/html/draft-ietf-json-i-json-06
I-JSON is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.
Main Contributor: Douglas Crockford
Editor: Tim Bray, Google, Inc. email: tbray@textuality.com

Stefan: AUTH48 status of draft-ietf-json-i-json-06 -> (RFC-to-be 7493)
This document is in AUTH48 state as of 2015-03-18. It has not yet been published as an RFC. The RFC Editor is awaiting approvals from the author(s) as shown below (and anyone else listed) before continuing the publication process. ...

Stefan (Update from 2015-MAR-22):

A new Request for Comments is now available in online RFC libraries.

RFC 7493

Title: The I-JSON Message Format
Author: T. Bray, Ed.
Status: Standards Track
Stream: IETF
Date: March 2015
Mailbox: tbray@textuality.com
Pages: 6
Characters: 12849
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-json-i-json-06.txt

URL: https://www.rfc-editor.org/info/rfc7493

I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.

This document is a product of the JavaScript Object Notation Working Group of the IETF.

This is now a Proposed Standard.
Date: Sun, 22 Mar 2015 09:32:52 -0700
Announcement Archived-At: http://mailarchive.ietf.org/arch/msg/json/g5cyKeTm2mnqFruOiYFWQIRe0NQ

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

5.1 OData ABNF Construction Rules

5.1.1 ODATA-774 "Qualifiers for annotations: Preference odata.include-annotations"

Ralf: Adapt the definition of the Preference odata.include-annotations:

 Allow in addition to the current definition 

   ns.term#qualifier 
   ns.*#qualifier 
   *#qualifier 

 and combined with the excludeoperator - 

   -ns.term#qualifier 
   -ns.*#qualifier 
   -*#qualifier

Mike: Added to proposal:

omission of #qualifier means all, regardless of qualifier
No way to specify "only unqualified"

John: ##?

Ralf:

annotationIdentifier = [ excludeOperator ]
                       ( STAR 
                       / namespace "." ( termName / STAR ) 
                       )
annotationIdentifier = [ excludeOperator ]
                       ( STAR 
                       / namespace "." ( termName / STAR ) 
                       )
annotationIdentifier = [ excludeOperator ]
                       ( STAR 
                       / namespace "." ( termName / STAR ) 
                       ) 
                       [ '#' simpleIdentifier ]

Mike: Added to proposal: ABNF needs to be updated to explicitly show a single hash followed by an identifier. This would preclude ## or #(nothing)

John: Likes second

Mike: I propose we resolve ODATA-774 as proposed. John seconds

ODATA-774 is resolved as proposed

5.1.2 ODATA-775 "Should allow use of parameter aliases for key lookup"

Mike: Not currently specified: Customers(@custID)?@custID='Alfki'

Ralf: Customers(ID=@custID)?@custID='ALFKI'

ODATA-775 is OPEN

Mike: Updated proposal: Support the use of parameter aliases in key predicates in both the short form and the long form.

Martin: I propose we resolve ODATA-775 as proposed. Mike seconds

ODATA-775 is resolved as proposed

5.1.3 ODATA-793 "Expand * on complex type"
$expand=ComplexProp/* 
$expand=ComplexProp/ComplexProp/* 
$expand=ComplexProp/model.type/ComplexProp/* 
$expand=model.type/ComplexProp/* 
$expand=model.type/ComplexProp/model.type/ComplexProp/*

ODATA-793 is OPEN

Mike: clarify that $expand=* means all navigation properties, independent of nesting in complex properties

Mike: Updated proposal:

1. * should include nav props on complex types (arbitrarily deep)
2. Allow for the * expand to be used on complex type properties as well as specific sub types as well....

Mike: The new ABNF for $expand would look something like:

expand               = '$expand' EQ expandItem *( COMMA expandItem )
expandItem           = expandStar
                     / expandPath 
                       ( expandNavigationProperty
                       / expandStar
                       )
expandPath           = [ ( qualifiedEntityTypeName / qualifiedComplexTypeName ) "/" ] 
                       *( ( complexProperty / complexColProperty ) "/" [ qualifiedComplexTypeName "/" ] )
expandNavigationProp = navigationProperty 
                       [ "/" qualifiedEntityTypeName ]
                       [ ref   [ OPEN expandRefOption   *( SEMI expandRefOption   ) CLOSE ]
                       / count [ OPEN expandCountOption *( SEMI expandCountOption ) CLOSE ]
                       /         OPEN expandOption      *( SEMI expandOption      ) CLOSE 
                       ]
expandStar           = [ STAR [ ref / OPEN levels CLOSE ] ]

Martin: I propose we resolve ODATA-793 as proposed. Jason seconds

ODATA-793 is resolved as proposed

5.2 OData CSDL

5.2.1 ODATA-795 "Support annotations for expanded references"

ODATA-795 is OPEN

Mike: Revised proposal:

Mike: Add two new annotations, applied to navigation link elements: "AutoExpandReferences" and "AutoExpand".

ExpandReferences says that the default behavior of the service is to expand just the references of the related resources, and ExpandResources says the default behavior of the service is to expand the related resources.

Such services may or may not support expand on those navigation properties.

Mike: Add two new annotations, applied to navigation link elements: "AutoExpandReferences" and "AutoExpand".

AutoExpandReferences says that the default behavior of the service is to expand just the references of the related resources, and AutoExpand says the default behavior of the service is to expand the related resources.

Such services may or may not support expand on those navigation properties

Martin: I propose we resolve ODATA-795 as proposed. Mike seconds

ODATA-795 is resolved as proposed

5.2.2 ODATA-796 "Add annotation to specify whether additional properties may be returned for an entity"

ODATA-796 is OPEN

NoAdditionalProperties
Sealed
Closed
AdditionalPropertiesDisallowed
DeclaredPropertiesOnly
OnlyDeclaredProperties

Mike: Revised Proposal:

Add a new tagging annotation, such as "OnlyDeclaredProperties", applied to an entity, that specifies whether the service is allowed to return additional properties not specified in $metadata.

This would include only properties. Services are still allowed to return instance annotations. JSON-Schema representation would include patternproperties for annotations.

Ralf: Use tagging annotation without default value

<Annotation Term="Core.AdditionalProperties" Bool="false" />

Mike: Revised proposal:
Add a new Boolean annotation, applied to an entity, that specifies whether the service is allowed to return additional properties not specified in $metadata.

Property could be "AdditionalProperties" (to match JSON Schema) and have no default value (require specify bool=false) or could be named something like "OnlyDeclaredProperties" and be a tagging annotation with a default of true when applied.

This would include only properties. Services are still allowed to return instance annotations. JSON-Schema representation would include patternproperties for annotations.

Mike: I move we resolve ODATA-796 as proposed. Martin seconds

ODATA-796 is resolved as proposed

5.2.3 ODATA-789 "Primitive type Edm.Decimal is ill-defined in regard to Precision"

Ralf: Decimal data types in programming languages and databases


Common terminology is:

Value = Mantissa * 10**(-Scale)

Precision = length of Mantissa

Positive Scale means fractional digits, negative scale avoids representing "trailing zeroes" for large integers, e.g. one million has mantissa = 1, scale = -6

Ralf: Type Precision = length of mantissa Scale = -Exponent


C# decimal 96 bit ~ 28-29 decimal digits Instance, 0..28
Objective-C NSDecimalNumber 38 decimal digits Instance, -128127
Java BigDecimal unlimited no of decimal digits Instance, -2,147,483,6482,147,483,647 (32 bit)
DECFLOAT34 34 decimal digits Instance, -384383
DECFLOAT16 16 decimal digits Instance, -61446143
DB2 DECIMAL 131 decimal digits Column, 0Precision
Sybase ASE DECIMAL 138 decimal digits Column, 0Precision
Sybase IQ DECIMAL 1126 decimal digits Column, 0Precision
Postgres DECIMAL 11000 decimal digits Column, 0Precision
Oracle NUMBER 1..38 decimal digits Column, -84127

Ralf: Problems when mapping these to Edm.Decimal

- missing exponential notation: the "floating-point decimals" can be declared as Scale="variable", but
-- with Precision=internal precision not all internal values can be represented in OData
-- with Precision=unspecified all internal values can be represented, using lots of zeroes, but not all OData values can be stored
- OData representation doesn't allow leading decimal point, numeric Scale has to be lower than precision
-- DECIMAL/NUMBER columns with 0 <= scale < precision fit perfectly
-- scale = precision runs into problems:
--- with Precision=internal precision not all DECIMAL values can be represented in OData
--- with Precision=internal precision plus 1 not all OData values can be stored as DECIMAL values
- Scale cannot be negative or larger than Precision minus 1
-- NUMBER columns with negative scale or scale larger than precision minus 1 run into the same problems as "floating-point decimals"

Ralf: Possible solutions

- define Precision to be the number of significant digits
- allow exponential notation
-- floating-point decimals can be minimally represented
-- Precision can be used to exactly express the number of significant digits
-- an annotation (or in future protocol versions a new facet) can indicate the presence of exponents and their value range
- allow Precision=Scale
-- DECIMAL precision and scale can be exactly expressed in all cases
-- number representation could be relaxed to allow .123, or we don't count the "0." into the Precision in this special case
- allow negative Scale
-- NUMBER precision and scale can be exactly expressed in all cases

All discuss request and payload WITHOUT any conversion

6. Next meeting

Suggested is 2015-MAR-26 8:00-10:00am PT

Agreed

7. AOB

None.

Meeting adjourned at 09:59 PT