Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

capabilities documentation #296

Draft
wants to merge 54 commits into
base: main
Choose a base branch
from
Draft

capabilities documentation #296

wants to merge 54 commits into from

Conversation

chrisspre
Copy link
Contributor

docs/rsdl/rapid-rsdl-capabilities.md
docs/rsdl/rapid-rsdl-capability-mapping.mdx

lisicase and others added 30 commits June 28, 2021 23:50
Co-authored-by: Ralf Handl <[email protected]>
* Drafted component to interactively make queries within documentation

* Styled results to be a scrollable box

* Created function to format queries so they work regardless of including the dollar symbol ($)

* addressed bugs/errors related to requests on unmounted components and incorrect transformation of URLs

* added interactive querying for all examples

* improved accuracy and efficiency of reformatting queries

* cleaned up code and added method comment

* reformatted query and results

* integrated intellisense query component

* reformatted/removed old version of template/example queries

* made stylistic changes to fonts, buttons, etc.

* implemented better responsivity with scrolling of query editor; documented code

* fixed parsing of JSON results

* Fixed occasional bug with rendering results by changing results format for CodeBlock

* removed unnecessary console log
| text | `<string op>(<property>, <literal>)`,<br/>where `<string op>` is one of `startswith`, `endswith`, `contains` |
| any | any expression including expressions combined with `not`, `and`, and `or` |

In RSDL this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sentence looks incomplete

Comment on lines +133 to +145
filter {
eq { id name description createdDate fulfillmentDate }
ranges { createdDate description }
prefix { name }
text { description }
}

filter {
eq except { description }
ranges { createdDate description }
prefix { name }
text { description }
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really two occurrences of filter {...}? Or should these be two separate examples?

traits {
longRunningOperation
topWithoutSkip
throttling { level: "premium\u12a4" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the values always strings, or can they also be arrays, objects, numbers, booleans, i.e. "embedded JSON"?

Comment on lines +275 to +277
targets: /orders
targets: unbound
# 'targets' ':' ( path / 'unbound' )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

targets sounds like plural: better use target?

Comment on lines +310 to +312
query-capabilities = [ expand-capabilities ] /
[ filter-capabilities ] / [ select-capabilities ] /
[ paging-capabilities ] / [ count-capabilities ] /
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better move after delete-capabilities for "hierarchical reading".

Comment on lines +20 to +28
```xml
<Annotations Target="skus">
<Annotation Term="Org.OData.Capabilities.V1.DeleteRestrictions">
<Record Type="Org.OData.Capabilities.V1.DeleteRestrictionsType">
<PropertyValue Property="Deletable" Bool="true" />
</Record>
</Annotation>
</Annotations>
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually we need to produce the complement, i.e. Deletable: false for all service members that have no path allowing DELETE, same for all other "default" capabilities.

<Annotations Target="skus">
<Annotation Term="Org.OData.Capabilities.V1.UpdateRestrictions">
<Record Type="Org.OData.Capabilities.V1.UpdateRestrictionsType">
<PropertyValue Property="Updatable" Bool="true" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<PropertyValue Property="Updatable" Bool="true" />

"true" is the default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am ok to not generate it but would suggest to keep it here to make it explicit.
If you think this is too distracting I might change it to a comment

<!-- by default <PropertyValue Property="Updatable" Bool="true" /> -->

Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can leave it in the generated output, but I'd remove it from the documentation as it has no effect.

<Annotations Target="orders">
<Annotation Term="Org.OData.Capabilities.V1.InsertRestrictions">
<Record Type="Org.OData.Capabilities.V1.InsertRestrictionsType">
<PropertyValue Property="Insertable" Bool="true" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<PropertyValue Property="Insertable" Bool="true" />

Comment on lines +114 to +119
```xml
<Annotations Target="skus">
<Annotation Term="Org.OData.Capabilities.V1.TopSupported" Bool="true" />
<Annotation Term="Org.OData.Capabilities.V1.SkipSupported" Bool="true" />
</Annotations>
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again: this is the default, need to opt out of paging

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to think a little but about generating this (or to be precise generating the false for the GET requests that do not contain paging

"orders": {
"@Org.OData.Capabilities.V1.FilterRestrictions": {
"$Type": "Org.OData.Capabilities.V1.FilterRestrictionsType",
"Filterable": true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"Filterable": true,

"Filterable": true,
"FilterExpressionRestrictions": [
{
"$Type": "Org.OData.Capabilities.V1.FilterExpressionRestrictionType",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"$Type": "Org.OData.Capabilities.V1.FilterExpressionRestrictionType",

Actually you'd have to produce

"@odata.type":"https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Capabilities.V1.json#Org.OData.Capabilities.V1.FilterExpressionRestrictionType"

See OData CSDL JSON, 14.4.12 Record

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not 100% sure I understand the details. Are you referring to The type of a record expression is represented as the @type control information, see

I would really like to understand the exact details on how this has to look because this is not directly generated by me but through the odata .net library which has to be fixed to serialize this correctly into JSON.
Any pointers would be appreciated.

Copy link
Contributor

@ralfhandl ralfhandl Dec 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and example 86:

"@person.Employee": {
  "@type": "https://example.org/vocabs/person#org.example.person.Manager",

The form is <URL to CSDL document>#<qualified name of type>, see OData JSON Format, 4.5.3 Control Information: type (odata.type).

Comment on lines +199 to +215
```xml
<Annotations Target="orders">
<Annotation Term="Org.OData.Capabilities.V1.ExpandRestrictions">
<Record Type="Org.OData.Capabilities.V1.ExpandRestrictionsType">
<PropertyValue Property="Expandable" Bool="true" />
</Record>
</Annotation>
</Annotations>
<Annotations Target="orders/items">
<Annotation Term="Org.OData.Capabilities.V1.ExpandRestrictions">
<Record Type="Org.OData.Capabilities.V1.ExpandRestrictionsType">
<PropertyValue Property="Expandable" Bool="true" />
</Record>
</Annotation>
</Annotations>

```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again we'll have to express the expand restrictions, and the new target syntax is not (yet) recognized by any tools.

What the OpenAPI generator already recognizes is this syntax:
https://github.com/oasis-tcs/odata-openapi/blob/15220b9a26a2e6c40ad4dd57e1712f275d23b08d/test/csdl2openapi.test.js#L1983-L1990

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants