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-910) Consider format that is tailored for programmatic access (public comment c201602e00002)

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

Ralf Handl updated ODATA-910:

    Environment: Proposed

> Consider format that is tailored for programmatic access (public comment c201602e00002)
> ---------------------------------------------------------------------------------------
>                 Key: ODATA-910
>                 URL: https://issues.oasis-open.org/browse/ODATA-910
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData JSON CSDL
>    Affects Versions: V4.0_CSD01
>         Environment: Proposed
>            Reporter: Ralf Handl
>             Fix For: V4.0_CSD02
> Public Review Comment https://lists.oasis-open.org/archives/odata-comment/201602/msg00002.html: 
> Hello!
> My team is consuming OData v4 in the browser as part of OpenUI5 with the goal to support business applications. Here are some comments based on this background.
> “This JSON format for CSDL is based on JSON Schema.”
> I fully understand the idea to express CSDL as s.th. which can be validated by a tool, but I think this is only one aspect. There is for sure a need for code to inspect the CSDL and react on it programmatically, not with a focus on validation, but on generic UI support (derive type information, labels, structures of tables or forms, etc.). I believe this can benefit from a JSON format which is tailored for programmatic access and not constrained by some validation tool’s data structures. Such code would have some knowledge about OData and its semantics, in contrast to generic validators which are unaware of that.
> I appreciate that the chosen MIME type “application/schema+json” leaves room for coexistence of such formats.
> “If the structured type has a base type, the schema contains the keyword allOf whose value is an array with a single item: a JSON Reference to the definition of the base type.” This is fine for validators, but unwieldy for normal _javascript_ access.
> “4.1.3 Enumeration Types”: The emphasis on member names is fine for human readability, documentation, debugging etc., but it does not help to build applications which are really fast. To do so, integers would be much better, both in data and meta data.
> I also wonder how valuable the “pattern” is: it allows for arbitrary number representations and quite useless string representations like “Red,Red,Red,Red,Red,…”? Again, a simple integer with a range or a list of allowed values should be easier, faster, safer.
> (4.3) “The entityContainer object may contain name/value pairs entitySets, singletons, actionImports, and functionImports.” This is a nice way to tell entity sets and singletons apart, but on the other hand, if you only got a name you need to look into different maps until you find it. At times, it is more convenient to look into a single map and then inspect a type information contained inside the resulting object.
> “An object describing an entity set must have an entityType”, “An object describing a singleton must have a type”: This inconsistency hurts sometimes.
> Ciao,
> Thomas

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]