OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

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