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

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

1. I put version into echoedSearchRetrieveResponse (I had been fooled into
believing it hadn't been in the earlier version). I put it at the front as
you suggested. 

I added 2.0 as one of the values. 

2. Now as to the xcql schema ... I wrote it from scratch. I don't think we
ever had a clean xcql schema  for earlier versions.  Is there an existing
implementation that takes an xcql query and contstructs a real cql query
from it?  And works?

--Ray



-----Original Message-----
From: Hammond, Tony [mailto:t.hammond@nature.com] 
Sent: Friday, June 18, 2010 5:58 AM
To: Denenberg, Ray; 'OASIS SWS TC'
Subject: Re: [search-ws] Untidy Arrangements: recordXMLEscaping and
recordPacking

Hi Ray:

Thanks for that schema change and for the explanations.

We've tested this and we've got a couple observations:

    1. version

    This is allowed as an optional element in searchRetrieveResponse. But it
isn't allowed on the echoedSearchRetrieveRequest element as it used to be.

    We would suggest adding this back in to the echoedSearchRetrieveRequest
element as an optional first child element.

    (And maybe a "2.0" label could be added to the enumeration if TC decided
that 2.0 could use optionally the version element.)

    2. xQuery

    The xcql schema changed! Whoa!! I can't remember the reasons for this
happening. Could you elaborate?

    Without any code change to support this we are going to have to suppress
this element in our responses because the content models are different. I
think that would be OK. Any ramifications?

Cheers,

Tony




On 17/6/10 20:45, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:

> Tony -
> 
> I've changed recordPacking and recordXMLEscaping to optional.
> 
> I took a look at the current 1.1 spec and noticed that recordPacking 
> is mandatory on the response (see
> http://www.loc.gov/standards/sru/sru1-1archive/xml-files/srw-types.xsd
> ) however I agree with you, they both should be optional, and I have 
> changed them both.
> 
>  
> On the question about:
> 
> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"
> processContents="lax"/>
> 
> This satisfies the desire to be able to gratuitously include arbitrary 
> elements from foreign namespaces, as you can do in ATOM and RSS. We 
> talked about this but I can't readily find that discussion - If you 
> are compelled to wrap them in extraRecordData and extraResponseData 
> then you lose flexibility, however we don't want to drop those 
> elements because then we would lose compatibility with earlier versions.
> 
> 
> This schema is (now) intended to be valid for all existing versions - 
> 1.1, 1.2, and 2.0. That's also a decision we made several months ago.  
> So a parameter that's in 1.2 but not 2.0 is in the schema but is 
> optional.  Even though it may be mandatory in 2.0. So it isn't a 
> completely tight schema, in that sense.  But that's why resultSetIdleTime
is still there.
> 
> So version is still in the schema for the same reason. But it's value 
> should be 1.0, 1.1, or 1.2.  2.0 would not be a valid value. (I'm not 
> completely sure what your question about version was.)
> 
> --Ray
> 
> -----Original Message-----
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: Thursday, June 17, 2010 12:21 PM
> To: Denenberg, Ray; 'OASIS SWS TC'
> Subject: Re: [search-ws] Untidy Arrangements: recordXMLEscaping and 
> recordPacking
> 
> 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
> 
> *********************************************************
> 


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