- From: chris mungall <cjm@fruitfly.org>
- Date: Sat, 4 Mar 2006 11:20:34 -0800
- To: Duncan Hull <duncan.hull@cs.man.ac.uk>
- Cc: public-semweb-lifesci@w3.org
On Mar 1, 2006, at 7:33 AM, Duncan Hull wrote: > > Matthias Samwald wrote: > >> XSLT definitly is not sufficient for such conversions, I agree. >> XQuery, however, is much more powerful than XSLT and has most >> features of a 'full blown programming language'. >> > > If you're trying to decide between XSLT and XQuery to perform some > task, this paper by Michael Kay is a good read. > http://www.idealliance.org/proceedings/xtech05/papers/02-03-01/ It's easy for XSLT to cross the line between elegant and nasty depending on the task. Anyone tried to do Muenchian transform using a composite key? Ewww. In my experience XSLT doesn't scale to large sources, you end up using imperative code to break up the source into multiple documents which defeats the purpose. The fact that you can use XQuery to efficiently query a relational db (by defining custom XML views) is a huge win for XQuery, although as far as I can tell such implementations are either proprietary (IBM's) or proof-of-concept (SilkRoute). I think both approaches are a little too XML-centric; fine for a few use cases but in general the syntax obscures the declarative semantics of the mapping which must be kept as perspicuous as possible. Why not just use an RDF query language? This could be used to query over generic DOM-as-RDF or relations-as-RDF mappings. This would seem to leave open plenty of room for optimisation, scalability - and the data sources could be queried directly (albeit slowly) rather than having to refresh your data warehouse. See also http://scholar.google.com/url?sa=U&q=http://www.ics.forth.gr/isl/ publications/paperlink/Koffina.pdf > > Duncan > > -- > Duncan Hull > http://www.cs.man.ac.uk/~hulld/ > Phone: +44 (0) 161 275 0677 > > >
Received on Saturday, 4 March 2006 19:23:04 UTC