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-1150) Case Sensitivity of Property Names, EntitySets, Singletons and Operations


     [ https://issues.oasis-open.org/browse/ODATA-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-1150:
------------------------------

    Description: 
In 4.01 we add support for case-insensitive system query options, operators, built-in functions and keywords.

We don't explicitly say whether property, entity set, singleton, or operation names are case-sensitive or case-insensitive
1) In URLs
2) In payloads

For response payloads, we should mandate that properties are written out in the case they are advertised.

In request payloads, should services support matching property names that differ by case (first looking for a case-sensitive match and, failing that, case insensitive?) or treat as dynamic?

What about in URLs? if resolution fails to find an exact match, should it look for a(n unambiguous) case-insensitive match, or treat as a dynamic property?

What about instance annotations and thus namespaces and aliases?


  was:
In 4.01 we add support for case-insensitive system query options, operators, built-in functions and keywords.

We don't explicitly say whether property, entity set, singleton, or operation names are case-sensitive or case-insensitive
1) In URLs
2) In payloads

For response payloads, we should mandate that properties are written out in the case they are advertised.

In request payloads, should services support matching property names that differ by case (first looking for a case-sensitive match and, failing that, case insensitive?) or treat as dynamic?

What about in URLs? if resolution fails to find an exact match, should it look for a(n unambiguous) case-insensitive match, or treat as a dynamic property?



> Case Sensitivity of Property Names, EntitySets, Singletons and Operations
> -------------------------------------------------------------------------
>
>                 Key: ODATA-1150
>                 URL: https://issues.oasis-open.org/browse/ODATA-1150
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: CSDL JSON , CSDL XML, JSON Format, Protocol
>    Affects Versions: V4.01_CS01
>            Reporter: Michael Pizzo
>             Fix For: V4.01_CS02
>
>
> In 4.01 we add support for case-insensitive system query options, operators, built-in functions and keywords.
> We don't explicitly say whether property, entity set, singleton, or operation names are case-sensitive or case-insensitive
> 1) In URLs
> 2) In payloads
> For response payloads, we should mandate that properties are written out in the case they are advertised.
> In request payloads, should services support matching property names that differ by case (first looking for a case-sensitive match and, failing that, case insensitive?) or treat as dynamic?
> What about in URLs? if resolution fails to find an exact match, should it look for a(n unambiguous) case-insensitive match, or treat as a dynamic property?
> What about instance annotations and thus namespaces and aliases?



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