 |
 |
Sorry Tony, I meant the SRU list. [log in to unmask] --Ray ----- Original Message ----- From: "Hammond, Tony" <[log in to unmask]> To: <[log in to unmask]> Sent: Friday, August 14, 2009 10:34 AM Subject: [search-ws] FW: SRU 2.0 Draft Feedback > > ------ Forwarded Message >> From: <Hammond>, Tony <[log in to unmask]> >> Date: Fri, 14 Aug 2009 13:54:30 +0100 >> To: <[log in to unmask]> >> Conversation: SRU 2.0 Draft Feedback >> Subject: SRU 2.0 Draft Feedback >> >> Hi: >> >> Here's some initial feedback on the SRU 2.0 Draft. >> >> Cheers, >> >> Tony >> >> >> ##### >> >> 1. Parameters / Elements >> >> I think it would help to break out Request Parameters from Response Elements >> in Sects. 4, 6 and 7. The two sets are largely disjoint. (Same remark applies >> to the Abstract Protocol Definition.) >> >> Also might help to break out discussion of Facets into separate section (as >> Diagnostics and Extensions), especially since Facets is an optional feature. I >> also think that Search Result Analysis is sufficiently specialized to warrant >> its own section. >> >> Sect. 5 seems to be misplaced coming as it does in between Sect. 4 and Sects. >> 6 and 7. >> >> >> 2. Parameter / Element Ordering >> >> Not clear what the basis is for the orderings given in Sect. 2 (Table 1) and 3 >> (Table 6). Is it a logical ordering? >> >> I note that "echoedSearchRetrieveRequest" is differently located (at bottom) >> from its location in the 1.* XSD schema. Is that intentional? >> >> <xsd:complexType name="searchRetrieveResponseType"> >> ... >> <xsd:sequence> >> ... >> <xsd:element ref="echoedSearchRetrieveRequest" minOccurs="0"/> >> <xsd:element ref="diagnostics" minOccurs="0"/> >> <xsd:element ref="extraResponseData" minOccurs="0"/> >> </xsd:sequence> >> ... >> </xsd:complexType> >> >> Also note that ordering is different in the tables and in Sect. 4. >> >> >> 3. Response Elements >> >> Response elements are given for a specific serialization - XML. >> >> Is that what is intended by binding? I would have thought binding would be to >> a specific data model (e.g. SRU) which can then be serialized various ways: >> native XML, ATOM, RSS, JSON, etc. >> >> Thus don't see relevance of the angle brackets in Table 6. (And that does also >> have a bearing on the type constraints that are offered if the elements are >> not only XML.) >> >> Also, heading in Sect. 3.1 is to "Actual Reponse Elements ..." and should be >> "Reponse Elements ..." only. (Cf Sect. 2.1 which is to "Request Parameters >> ..." alone.) >> >> >> 4. Response Elements: "resultSetIdentifier", "timeToLive", "idleTime" >> >> Mentioned in Sect 2, 3 and 4.10 the element "resultSetIdentifier" should be >> "resultSetId" everywhere. >> >> And in Sect 3, "timeToLive" and "idleTime" should be "resultSetTTL" and >> "resultSetIdleTime", respectively. >> >> >> 5. Response Elements: "diagnostics" >> >> Probably don't need the "(non-surrogate)" in the name value field. Perhaps >> this could be footnoted in the table? >> >> >> 6. Request Parameters: "httpAccept-*" >> >> I think these params are incorrectly named and should follow the standard >> camelcase style used elsewhere. e.g. >> >> Accept-Charset: httpAccept-charset -> httpAcceptCharset >> Accept-Encoding: httpAccept-encoding -> httpAcceptEncoding >> Accept-Language: httpAccept-language -> httpAcceptLanguage >> Accept-Ranges: httpAccept-ranges -> httpAcceptRanges >> >> Even though they mimic the HTTP headers they break naming convention. >> >> >> 7. Request Parameters: "rendering" >> >> This is just a query. I wonder if the terms "client" / "server" would be more >> appropriate than "local" / "remote". It might be more correct to talk about >> "local" / "remote" but I always end up having to do a double take to figure >> out my relative position. >> >> >> 8. Request Parameters: recordSchema, sortKeys/sortSchema >> >> Both "recordSchema" and "SortKeys/sortSchema" allow for short names to be used >> in place of URIs. But the SRU registered short names [1] are not unique. E.g. >> "mods" is mapped to four different XML schema (3.0, 3.1, 3.2, 3.3) and >> likewise "pam" is ampped to two different XML schema (2.0, 2.1). >> >> Also in Sect. 4.7.1 it says under sortSchema "the URI for an XML schema". What >> is meant though is the "short name" for an XML schema, which is a placeholder >> for the URI. And that is shown in the examples but needs better explanation. >> >> Still, the short name to URI mapping problem remains. >> >> [1] http://www.loc.gov/standards/sru/resources/schemas.html >> >> >> 9. Response ID >> >> There is no ID returned in the response. If there are records then a >> "resultSetId" is returned but not otherwise. Some serializations (e.g. ATOM) >> require an ID (actually a URI) for the response. One strategy would be to use >> the "resulSetId" as the basis for a unique ID, but this fails when no records >> are returned and a response is still required to carry the diagnostics. >> >> Is there some other place to return a unique response ID? >> >> >> 10. Endpoints >> >> I would have preferred to see the "operation" parameter maintained so that >> "searchRetrieve" and "scan" could both be located on the same endpoint, and an >> explicit choice be made between them. Heuristics could be applied but I think >> this is an unnecessary shorthand and may only lead to problems down the line. >> I would have made this parameter optional at the least. >> >> As regards version agree that it could be dispensed with although don;t see >> any real harm in allowing for an optional parameter. Definitely not a required >> parameter. >> >> >> 11. Typos, etc >> >> a) Sects 2 and 3 (Tables 1 and 6) >> >> Suggest that all categories which are not strict parameter names (e.g. "Facet >> parameters", "Extension parameters", "Extension", etc.) be set in italics to >> differentiate from actual parameter names. >> >> And some tidying up of punctuation etc., e.g. No periods on "Reference" / >> "Restrictions" columns (which by the way should both be the same head e.g. >> "Reference"?). And perhaps "see" instead of "See", and "optionsl" nstead of >> "Optional". >> >> b) 4.7.1 "Sort Sub Parameters" and "sub parameters" in text >> >> Preferably "sub-parameter" or "subparameter". >> >> c) 4.7.2 "Textual Representation of sortKeys Parameter" >> >> Maybe should just be something like "Represention of sortKeys Parameter >> Value". Don't need the "Textual", and this is the parameter *value*, not the >> parameter we're talking about. >> >> d) 4.9.1 >> >> Should everywhere be "HTTP Accept header" (lowercase "header"), and >> "Content-Location" (capitalized). >> >> ##### >> >> >> >> > > ------ End of Forwarded Message > > > ******************************************************************************** > DISCLAIMER: This e-mail is confidential and should not be used by anyone who is > not the original intended recipient. If you have received this e-mail in error > please inform the sender and delete it from your mailbox or any other storage > mechanism. Neither Macmillan Publishers Limited nor any of its agents accept > liability for any statements made which are clearly the sender's own and not > expressly made on behalf of Macmillan Publishers Limited or one of its agents. > Please note that neither Macmillan Publishers Limited nor any of its agents > accept any responsibility for viruses that may be contained in this e-mail or > its attachments and it is your responsibility to scan the e-mail and > attachments (if any). No contracts may be concluded on behalf of Macmillan > Publishers Limited or its agents by means of e-mail communication. Macmillan > Publishers Limited Registered in England and Wales with registered number 785998 > Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS > ******************************************************************************** > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >