 |
 |
> 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 //holdings/holding[library='mylibrary']/shelfmark Or perhaps //title[@lang="Eng"] //author[@type="primary"]/birthdate[@calendar="gregorian"] Etc. etc. 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 "wrong"... Matthew