> > Yes. We need it in Z39.50, and I think we need it here too.
> very slow communication speeds. Whilst I can think of hyperthetical
> situations in which this may apply in most cases transfering the
> additional data over the network is not such an overhead. Agreed sending
No, but processing it is. How do I display a quick hand list for
EAD in an SRU client written using javascript and xslt? I'd need to parse
ALL of the xml returned and then use the XSLT to extract the relevant
pieces. Urgh!
Even if I'm on a fast link (and not everyone will be) this is a vast
amount of processing that would need to be done. Certainly enough to
blitz IE or Mozilla off the map.
> offloading the process of extracting the required fields to the client
> might actually free up processing cycles on the server (i.e. be more
> efficient use of the server) - especially if the server uses xPath/XSLT
> to do this.
I thought the idea was to keep the clients simple to help implementation
efforts?
'Anyone can implement a client, but servers take more thought' seems like
a good model to me as there's many many more people who would want a
client than would want a server.
> In sort we use a very limited subset of the xPath syntax and strictly
Do we?
"XPath is a W3C specification which allows the description of an element
path. So to sort by title, one might specify the XPath of "/dc/title"
within the Dublin Core schema. The records need not be stored in this
particular schema to be able to sort by it. The records do not even
necessarily need to be able to be returned in the schema."
That doesn't imply a limited subset to me. Of course most people will
/implement/ a limited subset, but then if they implement the subset here,
why not for retrieval?
> At this point many would be tempted just to use their favourite xPath
> engine probably within an XSLT transform rather than write their own
> parser/handling for this type of xPath (this isn't easily done by look
> up tables any more).
Sure. And that might lead to a DDOS attack weakness. But as Mike would
say: Don't Do That Then. Client programmers can be lazy to a certain
extent, but server writing is hard [tm].
Just don't implement it. Or restrict it to known clients. Or *gasp*
implement it carefully with a thought to security. Or (at worst) just
ignore it and if it comes up fix it if it becomes an issue.
Rob
--
,'/:. Rob Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I
|