-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: V4.0_WD01
-
Fix Version/s: V4.0_WD01
-
Component/s: ATOM Format, JSON Format, Protocol, URL Conventions
-
Labels:None
-
Environment:
[Applied]
-
Proposal:
-
Resolution:
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?