ODATA-1370: Name uniqueness of operations and their overloads #244
Conversation
| @@ -200,7 +200,7 @@ type is the template for an entity: any uniquely identifiable record | |||
| such as a customer or order. | |||
|
|
|||
| The entity type's name is a [simple identifier](#SimpleIdentifier) that | |||
| MUST be unique within its schema. | |||
| MUST be unique among all direct children of its [schema](#Schema). | |||
There was a problem hiding this comment.
Name uniqueness within a schema sounds to me as if an action name cannot equal the name of a property of an entity type.
I hope this rephrasing makes it clearer.
| The action's name is a [simple identifier](#SimpleIdentifier). If two or more | ||
| actions within one [schema](#Schema) have the same name, they are called | ||
| [overloads](#ActionOverloads) of the same action. The name of an action MUST NOT | ||
| be used by any other direct children of its schema. (An action with a unique name | ||
| can also be viewed as an action with a single overload.) |
There was a problem hiding this comment.
What is the unique identifier of an "action"?
Is it the qualified name MySchema.MyAction,
or rather the qualified name plus the binding parameter type MySchema.MyAction() or MySchema.MyAction(MySchema.SomeType)?
Or put it the other way round: which beast is identified by the qualified name MySchema.MyAction? Which different beast is identified/referenced by the expression MySchema.MyAction()?
We need to name these two different kinds of beasts differently, and then use those different names consistently in the text.
Currently we say "if I find one beast by this qualified name, it is called an action, if I find two or more beasts, they are called action overloads".
There was a problem hiding this comment.
Correct, but I have tried to avoid that big renaming, especially since the JSON and XML versions point in different directions:
- In JSON, the schema child is the beast identified by
MySchema.MyAction(the collection of all overloads, even if there is only one). - In XML, the schema children are the beasts identified by
MySchema.MyAction(...)(the individual overloads).
Can we postpone this issue until we have written down our metamodel? This should make it clear.
No description provided.