Untidy Arrangements: recordXMLEscaping and recordPacking

["Hammond, Tony" <t.hammond@nature.com>]

Hi:

(Btw - I assume that the 'recprdXMLEscaping' typo will be globally fixed -
in doc and schema.)

I just reviewed the new treatment for 'recordXMLEscaping' and
'recordPacking' and found that these two complementary parameters are being
treated differently in that there is a corresponding <recordXMLEscaping>
element for each record in the XML response but no <recordPacking> element.

I had naively assumed that there would be a parity between the two.

Now I can see the logic for this insofar as the SRU/XML response only exists
in one state - packed. However, this does disadvantage the one parameter
from its relative.

I would propose one of two options:

    A. Both parameters are treated as 'local' and are named in each record
element:

       - even though for the SRU/XML response the unpacked form is identical
to the packed form, in other responses there may well be a marked difference

        - would need 'recordPacking' to be added to the schema record
content model

    B. Both parameters are treated as 'global' and are only mentioned in the
echoedSearchRetrieveRequest element:

       - note that recordXMLEscaping is actually a global flag and does
actually not select individual records

       - would need remove 'recordXMLEscaing' form the schema record content
model

My preference I guess would be for A (which is similar to current practice),
although I can see that B would provide for a simplification of response
record structuring.

I do not think the case anyway can be made to privilege recordXMLEscaping
over recordPacking.

Note anyway that 'recordPacking' needs to be added to the schema
echoedSearchRetrieveRequest element.

I am also confused by 'acceptParameter' and 'responseType' in
echoedSearchRetrieveRequest element. What is 'acceptParameter' for? And I
wonder if 'responseType' is the right name for an *echoed* request where
'httpAccept' is the actual parameter (if used) or 'accept' header is used.

(Where incidentally do other httpAccept* params fit into the
echoedSearchRetrieveRequest model?)


Text changes.

I think the 1st para 12.2 ('recordPacking') could be improved on (e.g.
'without forcing the client to go through he syntactic infrastructure' !)
and would volunteer to offer an alternative draft.

Also, sect 13 ('Echoed Request') might need some attention. It is not only
thin clients that may require this facility but more generally the ability
to recreate (or attempt to recreate) the response. It nevertheless provides
a record within the response of the query used to generate it. Which seems
to me the more major point that should be mentioned.

Would also need to say something about names possibly varying from request
parameters (e.g. 'httpAccept' and 'responseType' and/or 'acceptParameter').

Cheers,

Tony


 


********************************************************************************   
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   
********************************************************************************