RE: [odata-comment] Special values of numeric types

Hi Steve,

 

Thank you for the confirmation.

 

This is the correct mailing list, its intention is to allow providing feedback without having to be an OASIS member.

 

If you have further comments, issues, or questions, don’t hesitate to address then via this mailing list.

 

Thanks in advance

Ralf

 

From: Steve Lay [mailto:] 

Sent: Montag, 2. Oktober 2017 10:21

To: Handl, Ralf <>

Cc: 

Subject: Re: [odata-comment] Special values of numeric types

 

This appears to address the concern.  Thank you.

 

Hope this is the correct mailing list, I’m not an OASIS member so I’m not on odata-tc I’m afraid.

 

Steve

 

 

On 22 Sep 2017, at 08:30, Handl, Ralf <> wrote:

 

Hi Steve,

 

We’ve resolved https://issues.oasis-open.org/browse/ODATA-1103 and
 made changes to the following four documents:

1.     Part 2: URL Conventions – https://www.oasis-open.org/committees/download.php/61629/odata-v4.01-wd03-part2-url-conventions-2017-09-22.docx

2.     ABNF – https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/4.01%20spec/ABNF/odata-abnf-construction-rules.txt?op=diff&rev=1070

3.     CSDL JSON – https://www.oasis-open.org/committees/download.php/61625/odata-csdl-json-v4.01-wd02-2017-09-22.docx

4.     CSDL XML – https://www.oasis-open.org/committees/download.php/61626/odata-csdl-xml-v4.01-wd03-2017-09-22.docx

 

Can you please check whether this addresses your concerns, and provide feedback on the odata-tc mailing list?

 

Thanks in advance

Ralf

 

From:  [mailto:] On
 Behalf Of Handl, Ralf

Sent: Freitag, 11. August 2017 13:45

To: Steve Lay <>

Cc:  

 

Subject: RE: [odata-comment] Special values of numeric types

 

Hi Steve,

 

Thanks for your feedback.

 

I’ve created https://issues.oasis-open.org/browse/ODATA-1103 to
 track this additional aspect of -INF/INF for Edm.DateTimeOffset and Edm.Date.

 

Thanks

Ralf

 

 

From: Steve Lay [mailto:] 

Sent: Donnerstag, 10. August 2017 22:29

To: Handl, Ralf <>

Cc: 

Subject: Re: [odata-comment] Special values of numeric types

 

These changes address the issue with integers.

 

The addition of INF/-INF for date types does introduce a new ambiguity in the primitiveLiteral syntax though.

 

If I parse the value INF in an _expression_ I don’t know if it is meant to be a numeric or a Date (or DateTimeOffset) type.  Numeric types can all be cast to each other (within
 limits) so it doesn’t actually matter but in the proposed 4.01 my parser is likely to parse INF as doubleValue (or decimalValue now) and then, when attempting to use it in a context where a DateTimeOffset is required, the cast will fail and result in NULL.

 

The guidance here is interesting on whether to attempt INF/-INF with dates (look past the accepted answer too):

https://stackoverflow.com/questions/8011914/how-to-represent-end-of-time-in-a-database

 

PostgreSQL does use Infinity for both date types but (curiously) these special values appear to be timestamps internally (and will cast to Date as required) whereas the
 equivalent numeric values must be quoted (as strings) and presumably rely on cast from string to numeric.

 

It’s a tight corner!  The trouble is that primitiveLiteral has set out to enable numeric types and date types to be parsable without any special quoting which rules out
 any common representations (of non-castable types).

 

Given that you have maxdatetime and mindatetime as functions are you now going to have maxdatetime() return INF?  Or is there now a value of DateTimeOffset that compares
 greater than maxdatetime()?

 

Referring to the SO thread, it feels like you are trying to implement both patterns at once.  If you’re committed to maxdatetime I suggest sticking with that.  Otherwise,
 promote maxdatetime/mindatetime to being a special value (of type DateTimeOffset) instead of being a function.  You will need maxdate and mindate too.

 

Steve