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-1060) Improve specification of element response requirements


    [ https://issues.oasis-open.org/browse/ODATA-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65779#comment-65779 ] 

George Ericson commented on ODATA-1060:
---------------------------------------

OK, I see the disconnect.  
I had not considered it legal for the implementation to change published schema to reflect implementation.   
This is a significant divergence from prior practice in the DMTF and SNIA communities.
I’ll want to take time to study this.

I see this statement in Part 1, 11.1.2:
OData services MUST expose a metadata document that describes the data model exposed by the service. The Metadata Document URL MUST be the root URL of the service with $metadata appended. To retrieve this document the client issues a GET request to the metadata document URL.

I do not read ‘exposed’ by the service to also mean that standard schema is modified to reflect only implemented features.  This interpretation is problematic, how is a service upgrade handled?  

Is there other text that I should refer to?


> Improve specification of element response requirements
> ------------------------------------------------------
>
>                 Key: ODATA-1060
>                 URL: https://issues.oasis-open.org/browse/ODATA-1060
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>          Components: CSDL JSON , CSDL XML, Vocabularies
>         Environment: Schema
>            Reporter: George Ericson
>            Assignee: George Ericson
>
> Element response requirements:  
> There is ambiguity on the use and meaning of Nullable.  
> The reason is a distinction between the semantics of Nullable and whether or not implementation is required.  
> At least in one example, it is common practice to allow a Nullable=False property to be excluded from a response with the implied meaning of not implemented.  The implementation requirement is not a term defined by OData.
> Proposal:
> 1) Add the following Term to Core:
> <Term Name="ImplementationRequired" Type="Core.Tag" DefaultValue="false">
> <Annotation Term="Core.Description" String="If 'true', implementation of the qualified element is required. If the required element is Nullable and has no value, it may be omitted from a response.  Otherwise it must be present in a related response." If an element is not required, it may be omitted from a related response.  If an element is not required and is not Nullable and is not present in a response, it may be assumed to have not been implemented.  If the element is Nullable and not present in a response, it may either have no value or have not been implemented." />
> </Term>
> The following summarizes the above:
> a.	Nullable=True, Implementation=Optional => Omission implies no value or not implemented
> b.	Nullable=True, Implementation=Required => Omission implies no value
> c.	Nullable=False, Implementation=Optional => Omission implies not implemented, the value is unknown.
> d.	Nullable=False, Implementation=Required => Omission is not allowed, the property must indicate Null if no value.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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