jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Date Tue, 17 Jul 2007 14:17:11 GMT
I would really like to hear the reasoning behind this move, and soon. XPath
support was one of two ways to access data in v1 of the spec. I can't think
of a good reason to drop the support entirely, and can in fact think of
reasons why the second version of the JCR spec should go further than the
first and include XQuery, which goes much further than xpath can.

I think the new Java object query is probably going to have some very nice
features in certain use cases (ie. query by example). However, the choices
for querying in the new version just became:
1) SQL2
2) JQOM

SQL support is good, a lot of people know it, but its old and wasn't made
with hierarchical data structures in mind and JQOM will *assumably* be good,
but its specific to JCR. Why limit querying to a dated standard or something
that is specific to JCR when XQuery is a new standard specifically made to
support this use case and is supported by many of the vendors on the 283
committee? Not to mention the fact that everyone that used xpath in the
first version just got dumped by the wayside...

Furthermore, (leaving the dated and sometimes awkward SQL standard aside for
now) why should querying data in JCR (ie. JQOM) be different than querying
data from an XML database? Seriously, think about it...seems like we went
through this before with accessing relational databases in the 90's and JDBC
was defined so that we could access databases using a common standard. We
all agree that the JDBC standard was 'a good thing' right?
  -XQuery has been specifically defined to handle querying of hierarchical
data
  -Its a recommended standard from WC3
  -Many committee members support it and helped define it
Seems clear to me that it should be in the spec.

Regards,

Mark

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message