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] Updated: (ODATA-315) Entities that may be queryable can be omitted from service document, but then their "url" cannot be specified.

     [ http://tools.oasis-open.org/issues/browse/ODATA-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-315:

      Environment: [Proposed]
    Fix Version/s: V4.0_WD01

> Entities that may be queryable can be omitted from service document, but then their "url" cannot be specified.
> --------------------------------------------------------------------------------------------------------------
>                 Key: ODATA-315
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-315
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ATOM Format , OData CSDL, OData JSON Format, OData Protocol 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Evan Ireland
>             Fix For: V4.0_WD01
> CSDL spec (2013-03-19) states in section 12.2.3 "The IncludeInServiceDocument Attribute":
>   Entity sets that cannot be queried without specifying e.g. a $filter query option SHOULD specify the value false for this attribute.
> So that implies that some entity sets could be client-queryable (e.g. using a $filter) even though they are not mentioned in the service document.
> Also note that the protocol spec (2013-03-19) section 4 "Service Model" describeds a typical OData interaction with text that does not mention the client fetching the service document.
> Now herein lies the problem: A service document specifies a "url" for each exposed resource, in addition to a "name", with the implied assumption that the client must use the "url", not the "name", when formulating requests (otherwise the "url" would appear to be meaningless"). JSON format examples for service documents show "url" values that look just like unqualified entity set names.
> We therefore need to clarify:
> (1) Is the "url" in the elements of a JSON service document meaningless, i.e. can the client ignore this and just use the qualified (SchemaNamespace.EntityContainer.EntitySet) entity set name or unqualified name (for an entity set in the servic'es default entity container) when formulating a base URL for CRUD operations?
> (2) Does a client with access to the metadata document have ANY reason to need to fetch the content of the service document?

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


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