It is difficult to share functions because they are defined in an entitycontainer.
Functions should follow a similar model to Entities; the types should be defined in schema and we should use the entitycontainer to expose them at the container level, or to bind to particular sets within the container.
Field | Original Value | New Value |
---|---|---|
Component/s | OData CSDL v1.0 [ 10268 ] | |
Fix Version/s | WD01 [ 10247 ] | |
Affects Version/s | WD01 [ 10247 ] |
Proposal |
-Define a <Function> element used to define the shape of a function in the schema. The function definition defines parameters, return values, and may specify an entitysetpath. -Functions defined in the model are available for use by referencing the model. You do not need to "import them" into your container -The only time you use a functionimport is if you want to expose a function as a top-level function in your entitycontainer, or find a function to a specific entityset in your entitycontainer. Note that, if the return set is relative to the input set you can define this in the entitysetpath in the <Function> definition of the model, then you don't need to import it unless you want to expose it as a top-level function. -The FunctionImport always references a <Function> defined in the schema (similar to how an EntitySet always references an EntityType defined in the schema) -Functions should be bindable to primitive or complex types (or sets of primitive types) in addition to entities/sets of entities. |
-Define a <Function> element used to define the shape of a function in the schema. The function definition defines parameters, return values, and may specify an entitysetpath. -Functions defined in the model are available for use by referencing the model. You do not need to "import them" into your container -The only time you use a functionimport is if you want to expose a function as a top-level function in your entitycontainer, or find a function to a specific entityset in your entitycontainer. Note that, if the return set is relative to the input set you can define this in the entitysetpath in the <Function> definition of the model, then you don't need to import it unless you want to expose it as a top-level function. -The FunctionImport always references a <Function> defined in the schema (similar to how an EntitySet always references an EntityType defined in the schema) -Functions should be bindable to primitive or complex types (or sets of primitive or complex types) in addition to entities/sets of entities. |
Status | New [ 10000 ] | Open [ 1 ] |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Proposal |
-Define a <Function> element used to define the shape of a function in the schema. The function definition defines parameters, return values, and may specify an entitysetpath. -Functions defined in the model are available for use by referencing the model. You do not need to "import them" into your container -The only time you use a functionimport is if you want to expose a function as a top-level function in your entitycontainer, or find a function to a specific entityset in your entitycontainer. Note that, if the return set is relative to the input set you can define this in the entitysetpath in the <Function> definition of the model, then you don't need to import it unless you want to expose it as a top-level function. -The FunctionImport always references a <Function> defined in the schema (similar to how an EntitySet always references an EntityType defined in the schema) -Functions should be bindable to primitive or complex types (or sets of primitive or complex types) in addition to entities/sets of entities. |
-Define a <Function> element used to define the shape of a function in the schema. The function definition defines parameters, return values, and may specify an entitysetpath. -Functions defined in the model are available for use by referencing the model. You do not need to "import them" into your container -The only time you use a functionimport is if you want to expose a function as a top-level function in your entitycontainer, or find a function to a specific entityset in your entitycontainer. Note that, if the return set is relative to the input set you can define this in the entitysetpath in the <Function> definition of the model, then you don't need to import it unless you want to expose it as a top-level function. -The FunctionImport always references a <Function> defined in the schema (similar to how an EntitySet always references an EntityType defined in the schema) -Functions should be bindable to primitive or complex types (or sets of primitive or complex types) in addition to entities/sets of entities. Accepted: https://www.oasis-open.org/committees/download.php/48097/odata-meeting-23_on-20130130_31-F2F-minutes.html#odata-225 |
Assignee | Ralf Handl [ ralfhandl ] |
Resolution |
https://www.oasis-open.org/committees/download.php/48171/odata-core-v1.0-wd01-part3-csdl-2013-02-07-RH.doc https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/schemas/csdl.xsd?rev=175 |
|
Status | Resolved [ 5 ] | Applied [ 10002 ] |
Component/s | OData ABNF Construction Rules v1.0 [ 10269 ] | |
Proposal |
-Define a <Function> element used to define the shape of a function in the schema. The function definition defines parameters, return values, and may specify an entitysetpath. -Functions defined in the model are available for use by referencing the model. You do not need to "import them" into your container -The only time you use a functionimport is if you want to expose a function as a top-level function in your entitycontainer, or find a function to a specific entityset in your entitycontainer. Note that, if the return set is relative to the input set you can define this in the entitysetpath in the <Function> definition of the model, then you don't need to import it unless you want to expose it as a top-level function. -The FunctionImport always references a <Function> defined in the schema (similar to how an EntitySet always references an EntityType defined in the schema) -Functions should be bindable to primitive or complex types (or sets of primitive or complex types) in addition to entities/sets of entities. Accepted: https://www.oasis-open.org/committees/download.php/48097/odata-meeting-23_on-20130130_31-F2F-minutes.html#odata-225 |
-Define a <Function> element used to define the shape of a function in the schema. The function definition defines parameters, return values, and may specify an entitysetpath. -Functions defined in the model are available for use by referencing the model. You do not need to "import them" into your container -The only time you use a functionimport is if you want to expose a function as a top-level function in your entitycontainer, or bind a function to a specific entityset in your entitycontainer. Note that, if the return set is relative to the input set you can define this in the entitysetpath in the <Function> definition of the model, then you don't need to import it unless you want to expose it as a top-level function. -The FunctionImport always references a <Function> defined in the schema (similar to how an EntitySet always references an EntityType defined in the schema) -Functions should be bindable to primitive or complex types (or sets of primitive or complex types) in addition to entities/sets of entities. Accepted: https://www.oasis-open.org/committees/download.php/48097/odata-meeting-23_on-20130130_31-F2F-minutes.html#odata-225 |
Assignee | Ralf Handl [ ralfhandl ] | Ralf Handl [ handl ] |
As functions and actions are now schema children and function imports are only required for top-level functions we need to change the qualification rules for function and action names: they are now namespace- or alias-qualifed instead of container-qualified.