Changes between Version 85 and Version 86 of FCS-Specification-ScrapBook

Timestamp:

03/14/14 18:33:25 (10 years ago)

Author:

Oliver Schonefeld

Comment:

--

FCS-Specification-ScrapBook

@@ -347 +347 @@
 The Payload of a Data View can either be deposited ''inline'' or by ''reference''. In the case of ''inline'', it `MUST` be serialized as an XML fragment below the `<fcs:DataView>` element. This is the preferred method for payloads that can easily be serialized in XML. In the case of by ''reference'', the content cannot easily deposited inline, i.e. it is binary content. In this case, the Data View `MUST` include a `@ref` or `@pid` attribute that links location for Clients to download the payload. This location `SHOULD` be ''openly accessible'', i.e. data can be downloaded freely without any need to perform a login.
 
-Data Views are classified into a ''send-always'' and a ''need-to-request'' delivery policies. In case of the ''send-always'' delivery policy, the Endpoint `MUST` send the Data View automatically, i.e. Endpoints `MUST` unconditionally the Data View when they serialize a response to a search request. In the case of ''need-to-request'', the Client must explicitly request the Endpoint to include this Data View in the response. This enabled the Endpoint to not generate and serialize "expensive", i.e. Data Views that are "expensive" in terms of computational power or bandwidth, for every response. To request such an Data View, an Client `MUST` submit a comma separated list of Data View identifiers (see section [#endpointDescription Endpoint Description]) in the `x-fcs-dataviews` extra request parameter with the ''searchRetrieve'' request. If a Client requests a Data View that is not valid for the search context, the Endpoint `MUST` generate a non-fatal diagnostic `http://clarin.eu/fcs/diagnostic/4` ("Requested Data View not valid for this resource"). The details field of the diagnostic `MUST` contain the MIME type of the Data View that was not valid. If more then one requested Data View is invalid, the Endpoint `MUST` generate a ''separate'' non-fatal diagnostic `http://clarin.eu/fcs/diagnostic/4` for each of the requested Data Views.
+Data Views are classified into a ''send-always'' and a ''need-to-request'' delivery policy. In case of the ''send-always'' delivery policy, the Endpoint `MUST` send the Data View automatically, i.e. Endpoints `MUST` unconditionally the Data View when they serialize a response to a search request. In the case of ''need-to-request'', the Client must explicitly request the Endpoint to include this Data View in the response. This enabled the Endpoint to not generate and serialize "expensive", i.e. Data Views that are "expensive" in terms of computational power or bandwidth, for every response. To request such an Data View, an Client `MUST` submit a comma separated list of Data View identifiers (see section [#endpointDescription Endpoint Description]) in the `x-fcs-dataviews` extra request parameter with the ''searchRetrieve'' request. If a Client requests a Data View that is not valid for the search context, the Endpoint `MUST` generate a non-fatal diagnostic `http://clarin.eu/fcs/diagnostic/4` ("Requested Data View not valid for this resource"). The details field of the diagnostic `MUST` contain the MIME type of the Data View that was not valid. If more then one requested Data View is invalid, the Endpoint `MUST` generate a ''separate'' non-fatal diagnostic `http://clarin.eu/fcs/diagnostic/4` for each of the requested Data Views.
 
 The description of the Data View below types contain a recommendation, how the Endpoint should handle the payload deliver, i.e. if a Data View is by default considered ''send-always'' or ''need-to-request''. Endpoint `MAY` choose a implement different policy. The relevant information which policy is implemented by an Endpoint for a specific Data View is part of the ''Endpoint Description'' (see section [#endpointDescription Endpoint Description]).