> Yes. We need it in Z39.50, and I think we need it here too.
I can't help thinking that eSpec is a throw back to the days when we had
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
unused data over the wire might be inefficient - but on the other hand
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.e. I need a bit more convincing that this is something that is needed
rather than something a few people would think would be nice. I'm
concerned that eSpec is one of those clever things in Z39.50 which in
practice gets little use.
> I don't really buy the 'XPath is open to abuse' argument ... if so we
> should get rid of it from sort. Just because it's expressed in XPath
> doesn't mean you have to do it that way. You could simply
> have a big look
> up table.
In sort we use a very limited subset of the xPath syntax and strictly
speaking little of the semantics. We are also working at an abstraction
so there is no concrete record to apply an xPath or XSLT to.
For eSpec we could use a similar subset. However, I think that many
would start asking about qSpec too; the typical example for library
holdings data being something of the form
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).
Moreover, even without qSpec type xPaths, since we are dealing with
concrete record formats in this case, I suspect most implementors first
reaction will be the same as Ralph, namely I'll just drop the xPath
straight into my XSLT transforms. Without doing any sanity checking this
is potentially dangerous especially if the XSLT engine supports user
functions! You could argue this is a bad implementation, but I'd be
uncomforatble with any standard where the obvious implementation is