[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] Untidy Arrangements: recordXMLEscaping andrecordPacking
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 ********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]