>I'm confused about the //explain/serverInfo/database element and its
>First, the overloaded meaning that:
> - if it's Z39.50, "database" means the name of the database, but
> - if it's not Z39.50, "database" *may* mean the url path to the
> query script
Not quite. If it were being used to describe a non Z39.50, non SRW, non
OAI database, it might be just an identifier for the database or set of
records.
In SRW/U, the database element contains the path to the resource.
The document says:
"The database element should contain the name of the Z39.50 database
which the record describes. For other protocols such as SRW and SRU,
this element may be used to contain the remainder of the URL to the
server without any preceeding '/' character."
Which is slightly ambiguous, granted, but it's hardly a formal standards
document with MAY and MUST ala w3c :) Just replace 'may be used to'
with 'should' (or MUST if you like the w3c style)
>Second, may the serverInfo element repeat? If not, and you
>provide separate paths to both SRU and SRW (say, unalog.com/srw/
>and unalog.com/sru/, as an example), is the answer to say
>serverInfo[@protocol='SRW/U'] and then to duplicate the database element
>with one path for SRU and another for SRW? Hopefully not. :)
You can't repeat the serverInfo element. If you have different
endpoints which refer to the same collection via different protocols,
then the solution is to have multiple documents.
You might be interested in the draft of NISO Information Retrieval
Service Description Specification (aka ZeeRex 2.1):
http://www.lib.ncsu.edu/niso-mi/index.php/Subgroup_2_--_Services
[linked at the bottom of the page]
>recent "older version" from section 3 on the same page, DTD v2.0, is
>either the most current or close to it, the DTD itself seems to
>indicate that serverInfo must appear once, and cannot repeat.
That's correct, and I'll look into why the DTDs aren't showing up.
>Separately, is the scan action required for base-level compliance?
Nope :)
Rob
|