[OASIS Issue Tracker] Commented: (ODATA-253) Clients should be prepared to handle unadvertised properties

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32357#action_32357 ] 

Hubert Heijkers commented on ODATA-253:
---------------------------------------

I'm wondering how one would know if all properties were described in a PUT unless one retrieved all properties first. That by itself being fine, how would one know which properties to include in POST? Are we saying that these properties of this non open type would be optional and would only be round-tripped in a PUT request? Overall this implies that a client can't simply ignore properties that it doesn't know about any longer and therefore always will have to be able to deal with unadvertised properties even for non-open, read: all, entity types all the time?

> Clients should be prepared to handle unadvertised properties
> ------------------------------------------------------------
>
>                 Key: ODATA-253
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-253
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol v1.0
>    Affects Versions: WD01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: WD01
>
>
> Clients today may see unadvertised properties if a type is marked as open, but open also implies that the client can store properties not defined as part of the type definition.
> For extensibility, services should be allowed to return properties not advertised in metadata without marking the type as open (and implying that the service is capable of persisting properties arbitrary properties). This would allow, for example, $select to contain an expression, aggregations to return aggregated values, etc.
> We need to define the semantics of these unadvertised properties; i.e., must they be reflected back in a PUT (unless they are annotated as read-only) in order to prevent data loss when roundtripping
> Note that, for a request against an open type, the client would have no way of knowing if the property were a dynamic property (which would require specifying in PUT to avoid overwriting) or a property defined, i.e., in $select (which should not be specified in a PUT - note that the server cannot ignore these added properties in general because, if the type is marked as open, the server has no way to know how to distinguish between the client echoing back a read-only property (such as a projected expression) and the client attempting to persist a new open property. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira