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: recordPacking: No Schema Change Required


I just wanted to follow up with a remark I made in yesterday's call about
recordPacking and schema changes. I said there might, or would be, schema
changes, but in fact there wouldn't be any. This is the definition of

<xsd:element name="recordPacking" type="xsd:string" nillable="false"/>

i.e. any string goes. There is no restriction to any type enumeration.

So allowing for 'recordPacking=unpacked' is *not* a schema change. It would
only require a change in the text of the document.

From an SRU point of view an "unpacked" value for the "recordPacking"
parameter is strictly a logical generalization. It would have no real value
to an orthodox SRU response other than to vanish away the data (which in
some circumstances may be seen as a 'good thing').

From an OpenSearch point of view an "unpacked" value allows for the
overlaying of a full SRU response over the top of the host carrier format
and for a preprocessing to open up the contents of the SRU record and make
those available elsewhere within the response item format for easier access.
At which point, one might be tempted to say why bother with any SRU
vestigial response. But as well as holding true to the SRU data model this
does provide provenance information, e.g. the schema that was used
originally to marshal the data.

And by allowing for an SRU response (albeit unpacked) in the OpenSearch
response we are more consistent in providing for a fuller SRU conformance.
And we can make use of other SRU constructs such as diagnostics - rather
than reinvent those anew.

I really cannot see that there should be any objection to having this value
other than it be perceived as being worthless. It allows one to project a
more consistent OpenSearch/SRU duality.

Btw, on the schema front why ever this:

<xsd:element name="recordSchema" type="xsd:string" nillable="false"/>

Shouldn't this really be of type "xsd:anyURI"?

Seems to me that operating purely within the confines of an XML world we are
only at a halfway house to the web. We should really need to know that that
schema is at least globally identifiable - if not also globally retrievable.



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]