To briefly explain the current situation, with respect to XPath retrieval:
When you request one or more elements with recordXPath, the matching nodes
are included directly into recordData. This means that it may have
multiple root nodes, and if passed to an XML parser it will error.
Avoiding this is absolutely trivial: Simply wrap recordData in any
arbitrary element, and throw it away after parsing. This works for both
recordPacking types. Any client that is going to give the data to a
parser is clever enough to do this.
However, this arbitrary element could be made part of the protocol so that
clients don't need to worry about it. It might also make implementing
recordData as a choice of string or xml easier. To be useful, on the
other hand, it would need to be encoded as per recordPacking:
<srw:recordData>
<srw:data>
<dc:title>...
<dc:title>...
</srw:data>
</srw:recordData>
<srw:recordData>
<srw:data>
<dc:title>...
<dc:title>...
</srw:data>
</srw:recordData>
Not saying that we should do this, but it's something to think over as
string or known element is doubtless easier than string or sequence of any
element.
Rob
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I
