Hi Artem, On May 15, 2008, at 9:10 PM, Artem Melentyev wrote: Using xpath would be definitely easier to implement. However I agree it's not very user-friendly. SQL-like is going to be quite hard to implement (we'll need to use a JavaCC or Antlr grammar) but it's probably slightly more user- friendly, but not perfect either. The hard part is going to ensure that the grammar is complete IMO and the mapping with the underlying storage implementation (JCR or Hibernate). In that case, we should probably make our query module generic and independent of the storage module. Then the SPI implementations for the given storage modules can restrict what's allowed and what's not allowed maybe? The mapping is really going to be the hard part. I think we should offer an even simpler DSL for querying objects and object properties in xwiki documents that can be used by non developers. Either something like http://code.xwiki.org/xwiki/bin/view/Macros/RequestStructuredDocumentsMacro or a generic query language but very simple and working only on documents, objects and classes. More generally: I'd really like that we have a design that supports multiple query languages by having a QueryManager component designed like http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/query/QueryManag… In that way we could support XPath, SQL and the new query language we're talking about. I sent the following mail below on September 2007 about this but I couldn't find it on nabble or markmail so maybe it never reached the list for some reason: ===start here==================== Hi, I'd like to start designing the v2 of the Storage/Query API. Current issues: ============= * Current XWikiStoreInterface is too broad, having business methods for anything that can retrieved from the store. * Business methods should be located in the Model. For example, getDocumentNames() should be located in the Wiki object representing a wiki. * There's currently no object for manipulating queries so there are lots of duplications Requirements: ============ * Solve current issues listed above * The store interface should be simple and have a minimal number of method. I can imagine one for now: List executeQuery(Query query); * It should allow for new query languages and support the current HQL syntax Proposal: ======== * Create a new module in core called xwiki-store * Use the new component model * Have the following classes/interfaces in it: - Store List executeQuery(Query) - HibernateStore: implementation of Store for Hibernate - CacheStore: caching implementation of Store - Query (interface) - HibernateQuery: implementation of Query for HQL - (later) JCRQuery: implementation of Query for JCR Usage: ====== HibernateQuery query = new HibernateQuery("select * from ...."); query.addParameter(index, value); // for named HQL queries List results = store.execute(query); Notes: ====== * This proposal is backward compatible with current code * Slowly move current code to use the new code, deprecating methods/ classes as we progress * There are some overlaps with the query plugin

XPath makes a lot of sense and user friendliness if we ignore its (scary) name: if we look at a wiki as a file system, XPath is perfectly usable as a file system path referencing: all data would be nodes, all metadata would be attributes. I think that, put this way, besides being clear as daylight for developers (as Thomas mentioned), it can also be easily understandable by users (as Guillaume proved). Besides that, since it is based only on a few simple rules (once axis implemented), we would be exposing less unimplemented features to the user than with our own, sql-like-but-not-quite-sql query language. As well, an XPath query language would allow us to implement the support of sheets (currently Velocity code or Groovy code) as XSL Sheets, using the wiki as one big input document. I know I would definitely love this 'feature'. Of course, I agree that SQL might be a little more natural or easier for users / developers, but I think its popularity and it being here for a longer time than XPath has much to do with it. 3. so I'm for full, clean XPath Happy coding! Anca Luca