RE: [search-ws] Untidy Arrangements: recordXMLEscaping and recordPacking

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

Tony - I've "tidied" up the schema a bit this afternoon. And as it turns out
I didn't have quite the most up to date version out there (a few late
changes I had made hadn't gotten out to the server).  

Anyway, I think the recordXMLEscape issue is resolved. 

The "acceptParameter" I changed to httpAccept.  I had had it listed as
acceptParameter as a generalization of the several accept parameters and
made it repeatable, but since we are going to eliminate the sub parameters
there's no need for that.

Please look it over. I think it is fairly close to stable, but I can make
any additional necessary changes tomorrow or Friday, before I go away for a
week.

--Ray

-----Original Message-----
From: Hammond, Tony [mailto:t.hammond@nature.com] 
Sent: Saturday, June 12, 2010 8:33 AM
To: Denenberg, Ray; OASIS SWS TC
Subject: [search-ws] Untidy Arrangements: recordXMLEscaping and
recordPacking

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


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