Re: [search-ws] Untidy Arrangements: recordXMLEscaping andrecordPacking

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

Hi Ray:

Thanks for this. Is looking good but was getting some errors with validating
my test with facets. Will need to spend some more time tomorrow. Something
in my content model seems to be adrift.

Some points below. (Btw, am trying to figure out if this is a 2.0 stylesheet
or a universal 1.*,2.* stylesheet as it contains a lot of 1.* references.)

[1] For now, I note that both recordPacking and recordXMLEscaping are
reported in each record. Which I think is good, but I would strongly suggest
to make both optional elements.

[2] Also, I didn't recall exactly why this was included in both
recordDefinition and searchRetrieveResponseDfinition content models:

==
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"
processContents="lax"/>
==

Why? I thought we had the extraRecordData and extraResponseData elements for
extensibility?

[3] Why is recordIdleTime still present with recordTTL added below
extraRecordData. Why isn't -TTL replacing -IdleTime above?

[4] Is version still OK? Am happy with it being optional.

[5] Hmm, and while we're here what about this:

    <xs:simpleType name="versionDefinition">
        <xs:restriction base="xs:string">
            <xs:enumeration value="1.0"/>
            <xs:enumeration value="1.1"/>
            <xs:enumeration value="1.2"/>
        </xs:restriction>
    </xs:simpleType>

So, in summary the one real change needed for now is [1] - making both
recordPacking and recordXMLEscaping optional.

Cheers,

Tony



On 16/6/10 21:26, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:

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


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