OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata-comment message

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


Subject: RE: [odata-comment] Public review for #OData JSON Format for Common Schema Definition Language (CSDL) V4.0 - ends February 26th


Hello!

 

Here’s some miscellaneous feedback about inconsistencies and the like.

 

 

(4.1.1) „If the key property has a key alias, the item is an object with one name/value pair, the name is the key alias and the value is the property path name and optionally a name/value pair alias.

I don’t get the yellow part. The example "keys": [{"EntityInfoID": "Info/ID"}] does not seem to cover this case.

·         “Example 32: nullable property Price of type Edm.Decimal with precision 15 and scale 3”

·         "Price":{

·           "type":["number","string","null"],

·           "precision":15,

·           "scale":3,

·           "multipleOf":1e-3,

·           "minimum":-999999999999.999,

·           "maximum":999999999999.999

·         }

I think it would be convenient to find the same information present in $metadata’s XML representation also in JSON, namely the type “Edm.Decimal” and the flag “nullable”. The way these are currently represented for validators means that any code that understands OData needs to reverse engineer this information first.
But maybe "format":"decimal" is simply missing here and thus does the job?

 

 

1.1.1.1 Path Expressions

The expressions edm:AnnotationPath, edm:NavigationPropertyPath, edm:Path, and edm:PropertyPath are represented similar to individual properties or operation responses in [OData-JSON], chapter 11, as a JSON object with a name/value pair @odata.annotationPath, @odata.path, or @odata.propertyPath whose value is a string containing the path _expression_.

The 2nd list does not contain @odata.navigationPropertyPath.

 

 

1.1.1.2 _expression_ Apply

The dynamic _expression_ edm:Apply is represented as a JSON object with an @odata.apply name/value pair whose value is the function name as a string value. The child expressions are represented as a parameterValues name/value pair whose value is an array with items that are representations of the child expressions according to the rules defined in this specification.

It may also contain annotations.

Example 51: edm:Apply _expression_ with two edm:String expressions and one edm:Path _expression_ as parameter values

"@Some.Computed.Url":{

  "@odata.apply":{

    "function":"odata.concat",

    "parameterValues":[

      "Products(",

      {

        "@odata.path":"ID"

      },

      ")"

    ]

  }

}

Something is strange here. I think the yellow part means „@odata.apply“ : „odata.concat“. But that’s not what the example shows. Maybe parameterValues belongs to the top-level, next to @odata.apply, like it is the case for Cast/IsOf?

 

Similar to „If“ the following representation would also be logical. The annotation with name “@odata.apply” points to the values while an extended annotation (or maybe an annotation of the annotation “@odata.apply@odata.function”?) provides the function name:

"@Some.Computed.Url":{

  "@odata.apply":[

      "Products(",

      {

        "@odata.path":"ID"

      },

      ")"

    ],

  "@odata.apply.function":"odata.concat"

}

 

 

1.1.1.3 _expression_ Not

The dynamic _expression_ edm:Not is represented as a JSON object with an @odata.not name/value pair whose value is the representation of the child _expression_ according to the rules defined in this specification.

I’m missing “It may also contain annotations.”!

 

 

1.1.1.4 _expression_ Null

If the dynamic _expression_ edm:Null contains annotations, it is represented as a JSON object with an @odata.null name/value pair whose value is an object that may contain annotations.

Why do annotations not live next to @odata.null, like it is the case for @odata.if etc.?

 

And wouldn’t the following be simpler?

Example 57: edm:Null _expression_ without nested annotations

"@Some.Term": {

  "@odata.null":null

}

Or even…?

Example 57: edm:Null _expression_ without nested annotations

"@Some.Term": null

 

 

1.1.1.5 _expression_ UrlRef

The dynamic _expression_ edm:UrlRef is represented as a JSON object with an @odata.type name/value pair whose value is #UrlRef. Its single child _expression_ is represented as a value name/value pair whose value is the representation of the child _expression_ according to the rules defined in this specification.

Example 58: edm:UrlRef expressions with edm:String value and with edm:Path value

"@Good.Reference#one":{

  "@odata.urlRef":"http://www.odata.org"

},

"@Good.Reference#two":{

  "@odata.urlRef":{

    "@odata.path":"DocumentationUrl"

  }

}

The text does not fit to the example, but I think the example is better and should win ;-)

 

Ciao,

                Thomas

 

Dr. Thomas Chadzelek
Development Architect, PI Technology User Interface (SE) - Web Technologies
SAP SE, Neue Bahnhofstr. 21, 66386 St. Ingbert, Germany

T   +49 6894 981-2029, E   thomas.chadzelek@sap.com

Please consider the impact on the environment before printing this e-mail.

 



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