Changes between Version 68 and Version 69 of FCS-Specification-ScrapBook

Timestamp:

03/04/14 15:50:32 (10 years ago)

Author:

Oliver Schonefeld

Comment:

--

FCS-Specification-ScrapBook

@@ -24 +24 @@
  9. Do we want to keep Images (IMG) and Geolocation (KML) as defined Data View in "basic" profile?
 
-== TODOs for the current draft / Preliminary items identified by discussion ==
- 1. '''Generic Hits as lowest common denominator''': Add to description/change wording of Generic Hits Data View, that it is deliberately intended as the ''lowest common denominator'' to serialize search results (and therefore often is only be an approximation).
+== TODOs for the current draft / Preliminary items identified by discussion (in no particular order) ==
+ 1. ''Generic Hits'' Data View
+  1. Generic Hits as ''lowest common denominator'': Add to description/change wording of Generic Hits Data View, that it is deliberately intended as the ''lowest common denominator'' to serialize search results (and therefore often is only be an approximation).
+  2. Change wording to indicate, that `<Hits>` element is optional, but make clear that Endpoint should use it
  2. '''Restrict query scope''': By default, Endpoint should query all resources, if no `x-clarin-fcs-context` parameter is supplied by the Client (as described already in the draft). If that is for some reason ''not feasible/possible'' for an Endpoint, it MAY restrict the search to whatever scope it thinks it can handle ''and'' MUST issue a non-fatal diagnostics (URI tbd), like "collection set too large. query context automatically adjusted" (and include the PIDs of the collections comma separated in the details field. Furthermore, we should introduce a fatal diagnostic "collection set too large. cannot perform query" (URI tdb) to be issued by the Endpoint, if it feels the Client requested too many collections with `x-clarin-fcs-context`. \\ In FCS, we MUST avoid a situation, where an Endpoint needs special treatment (e.g. by unconditionally requiring `x-clarin-fcs-context`) to return any results. With the solution above, we could get at least some results and the Endpoint can indicate, that users need to "do more" to search broader.
  3. '''Explicitly list supported Data Views by collection''': Amend the Endpoint Description to explicitly encode which Data Views are supported by a given collection. The semantics between parent-child is, that children `MUST` "inherit" the Data Views of the parent, i.e. a child collection must support all Data Views supported by the parent collection. Something along the lines of:
@@ -77 +79 @@
     This is nor yet very useful for the ''basic'' Profile, but will be useful for ''extended'' Profile(s).
  5. '''Need-to-Request Data Views''': Data Views will be classified into a "send-by-default" and a "need-to-request" class (which need to be documented in the spec analogous to the payload disposition). The first would indicate, that the Endpoint will include this data view unconditionally, e.g. the Generic Hits view. For the second class, a Client explicitly needs to request the Data View by using another custom query parameter (`x-clarin-fsc-request-dataviews`?) and supplying a (list of) data view(s). The Endpoint Description should also indicate to which class a data views to. This way, Endpoints could also indicate, that they e.g. always include some data view, that has been marked as "need-to-request" by the spec. This change would enable FCS to add/define Data Views that are too "expensive" (e.g. in terms of computational power or bandwidth) to generate for every request.
-
+ 6. Shorten `x-clarin-fsc-*` parameters to `x-fsc-*`.
+ 7. change wording add default recommendation for hits granularity to make clear that, Endpoint shall provide one hit within one `<sru:record>`. If multiple hits occur within one resource, and endpoint must serialize each hit as an individual record. Endpoints are expected to do this on best effort basis.
+ 8. change wording to indicate, that an Endpoint `MUST` support Endpoint Description in ''explain''
+ 9. Endpoint Description
+   1. change element names `<Collection*>` to `<Resource*>`; that's more coherent with the other parts of the spec
+   2. drop `<Profile>` element; also need to revise section about profiles to introduce capabilities
+   3. add extension hook to 
+ 10. Separate Data Views from Core-Spec; add them in an appendix, if a "one document" spec is compiled. Generic Hits however will also stay in Core-Spec, because it's the lowest common denominator
 
 == Proposal for new specification ==