[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 ]
Michael Pizzo updated ODATA-315:
--------------------------------
Proposal:
Specify clearly in the URL conventions specification how a client with the information in the metadata document, but without accessing any information from the service document, can correctly formulate a URL to designate any entity set (or entity, function, or action) with a suitable qualified name (SchemaNamespace.EntityContainer.SomeThing, whether or not it lies in the default entity container) or unqualified name (SomeThing, for items within the service's default entity container).
Also clarify the purpose of "url" in the JSON format service document (or eliminate it entirely), and specify the conditions under which an unqualified "name" can appear in the service document (i.e. only for "things" in the service's default entity container).
Proposal from meeting:
1. JSON: add "title" name-value pair, optional, may contain "atom:title" if different from entity set name
2. ATOM: add optional metadata:name attribute for correlation with $metadata to app:collection, metadata:function-import, metadata:entity. may be omitted if same as title.
was:
Specify clearly in the URL conventions specification how a client with the information in the metadata document, but without accessing any information from the service document, can correctly formulate a URL to designate any entity set (or entity, function, or action) with a suitable qualified name (SchemaNamespace.EntityContainer.SomeThing, whether or not it lies in the default entity container) or unqualified name (SomeThing, for items within the service's default entity container).
Also clarify the purpose of "url" in the JSON format service document (or eliminate it entirely), and specify the conditions under which an unqualified "name" can appear in the service document (i.e. only for "things" in the service's default entity container).
> 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]