LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  November 2001

ZNG November 2001

Subject:

Betr.: Re: general remarks

From:

Theo van Veen <[log in to unmask]>

Reply-To:

Z39.50 Next-Generation Initiative

Date:

Fri, 23 Nov 2001 15:01:45 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (166 lines)

I am a little bit concerned about the responseSchema. My dream (and I hope we had the same dream) was that we could come to some standard protocol that would work always and for every SRW-target and SRW-client. Having different resonseSchemas should definitely not introduce interoperability problems. When I introduce a responseSchema to do things my own way, than that declines from the standard than that is not what I want. 
Of course we will have some local extras and others will probably others will also have their local extras. But a minimum requirement should be that our clients (just html-pages and stylesheets) are capable of doing basic searching in all SRW-targets and the all other clients should be capable of searching in our databases. When I introduce a new responseSchema to make life easier for me, than that does not make sense if that responseSchema doesn't work for other targets. 

So I try to conform to the standard and try to find my way around some problems. But we have to avoid the need for extra responseSchemas. I think that accepting the following will help improving the standard in this respect and will make it more dynamic without adding complexity and without the need for introducing extra responseSchemas.

1) Allowing clients without state (browsers do not keep state between pages) by returning the original url parameters as xml-tags in the response.   
2) Allowing for url-parmeters that are not defined in the standard. If desired, some of these parameters can always become part of the standard. 
3) Allowing for extra (even unsollicited) responses sibling to searchRetrieveresponse rather than instead of searchRetrieveresponse. E.g. it would improve the overall quality of a search and retrieve protocol if "no hits" would automatically lead to a list (in xml) with best matching entries). If the stylesheet or client can handle this response it's fine, when it cannot, it won't harm.

Theo


>>> [log in to unmask] 20-11-01 16:03 >>>
> -----Original Message-----
> From: Theo van Veen [mailto:[log in to unmask]] 
>
> First lets keep SRW simple and make sure that the
> implementation barrier is low so that implementation becomes
> possible for a large group of people. It should for regular
> metadata like (title, author etc.) always be possible to
> create XML output without the need for SOAP and which can be
> presented on the client with just an XSL-stylesheet.
> Extensibility and interoperability are in many cases a matter
> of simplicity. So forget about new mime-types and lets stick to XML.

There need be no relationship between SOAP and the generation of XML.  My
server is making the XML on the fly and returning it in a SOAP wrapper in
response to a SOAP request.


> Interoperability is also a matter of being strict in
> agreements that do not interfere with functionality (like
> agreeing on the use of prefixes, recordnumbers, fixed record
> schemas, query syntax etc.)

Prefixes are not something that can be controlled.  They are often generated
automatically by the XML tools.  Besides, they don't really exist.  If you
replace the prefix with the actual URI that they represent, then your
version of the XML tag and my version should be identical.

I agree that we need to agree on some record schemas.  We've loosely agreed
on DC and ONIX as those schemas, but that agreement needs a little rigor.

We will need to eventually agree on the details of the query syntax, but I
am happy to let that one evolve with some implementor experience.

Adding record numbers to the base agreement is a step away from simplicity.
It assumes a client with no state.  If we accept that assumption then we'll
need to add a lot of other things besides record number.  While I'm
sympathetic to those requirements, I don't want them in the base standard.
They are exactly why responseSchema is a parameter in the request.


> And interoperability is also a matter of tolerance with
> respect to those aspects that have to do with extensible
> functionality (like allowing extra url-fields in the request
> and extra xml tags or xml response  blocks in the response
> without being predefined).

Sorry, but I don't understand either of these two issues.


> We want to make SRW the main extrance to our OPAC and other
> databases as soon as possible but at the same time we want to
> conform to a standard. I want to mention here the things for
> which our current implementation declines from the current
> standard and that I would like to become part of the standard
> or have alternatives suggested to me.
>
> 1) We use recordnumbers in the xml-output to allow browsing
> without the need for keeping session context

Specify your own responseSchema that contains that information.


> 2) We allow the stylesheet-url being put in the request
> (xsl=http:// ...), so that the SRW-server can put this in the
> XML-header, so that it can be used by Internet Explorer automatically.

Clever idea.  But, it would require an additional parameter in the request
and I'm disinclined to add that complexity to work around a temporary IE
problem.  The real fix is the ability to specify to IE a table that maps
record schemas to stylesheets.


> 3) We allow three three record schemas: kb_caption, kb_record
> and dc. The first to are for internal use only, for dublin
> core I want to suggest dc_record (full record) and dc_caption
> (brief presentation) as being minimal requiered for
> interoperability purposes.

My implementor experience is that I always ask for the full record, even for
brief displays, because my definition of the necessary fields in a brief
display rarely corresponds to the definition used by the server.


> 4) We return unknown url-fields as xml-tags that can be used
> by external applications to keep session context.

Sorry, but I don't understand this one.


> 5) We have the field zng:recordid in the xml and recordid as
> url parameter to allow for requesting records by means of
> some identifier outside the scope of a resultset.

Gosh, we've never done that in regular Z39.50, so I don't want to do that
here.  A strict rule for use must be semantic interoperability with Z39.50.

In the case of SRW, I don't even see the need for this, since all record
requests can be accompanied with a query.


> 6) We do not yet use the parameter responsschema. Is
> searchRetrieveResponse one of the responsschemas or will
> different responsschemas be part of the searchRetrieveResponse.

As I've been discussing with Alan and Matthew, we've got a conflict in
requirements.  A strict SOAP RPC interpretation would say that
responseSchema is meaningless, because responses are not defined by a
schema.  They are defined as an object specified in the WSDL.

For responseSchema to be meaningful, then the response to a request needs to
be an XML record whose contents can vary, depending on the responseSchema.
That is not what we currently have defined in our WSDL, but that is what I'm
returning out of my server.

I've suggested that we need to support both mechanisms and I'm waiting for
responses.


> 7) We use zng: and dc: prefixes. I do not know how to specify
> in xsl or xslt a current namespace. I want to suggest agree
> on using prefixes.

Sorry, but we can't do that, for the reasons I gave above.

If by "current namespace", you mean default namespace, then maybe I can help
with that problem.  This article explained everything I needed to make XSLT
work for me with default namespaces.
http://www.topxml.com/people/bosley/defaultns.asp.  (I'm using XSLT to make
the DC records in my responses and I spent a half day beating my head
against the default namespace problem before I found this article.)


> 8) Within a query I use field:term (e.g. author:smith), but
> is there already agreement on using some character to
> separate field and terms?

That's part of the stuff to be agreed on.  In my original CQL proposal, I'd
suggested some additional characters but I have since reconsidered that
decision.  For right now, I think the colon is the correct character to use.


> As I have said before in important use of SRW will be in
> local applications with just a stylesheet for presentation in
> Internet Explorer. I would be disappointed when SRW could not
> be used for that kind of application and this only requires
> XML responses to be selfcontaining (which alos increases robustness)

As I've said before, I'm sympathetic to this requirement and will try to get
it into our agreements.  But my highest priority is to simplicity in the
protocol.

Ralph

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

July 2017
October 2016
July 2016
August 2014
February 2014
December 2013
November 2013
October 2013
February 2013
January 2013
October 2012
August 2012
April 2012
January 2012
October 2011
May 2011
April 2011
November 2010
October 2010
September 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
October 2009
September 2009
August 2009
July 2009
May 2009
April 2009
March 2009
February 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager