JCR 2.0 under public review

Discussions

News: JCR 2.0 under public review

  1. JCR 2.0 under public review (15 messages)

    The next major revision of the Java Content Repository (JSR-283) has entered public review status on the JCP web site. Most of the visible changes revolve around querying a repository for content, with the SQL and XPath query languages being deprecated. JCR is gaining acceptance in the market, with open source vendors like Alfresco, Apache, Magnolia as well as commercial vendors such as Day, and Percussions available. (Note: this is very far from an exhaustive list, although it'd be nice to have an exhaustive list somewhere...) The revision to the specification is an excellent step forward.

    Threaded Messages (15)

  2. Most of the visible changes revolve around querying a repository for content, with the SQL and XPath query languages being deprecated.
    Wow, that's venturous!
  3. Most of the visible changes revolve around querying a repository for content, with the SQL and XPath query languages being deprecated.
    Wow, that's venturous!
    Well, in all fairness, this is a fairly large change - and the XPath and SQL queries were a little clunky. So if there was going to be a major revision, that's a fine area - IMHO - to start with.
  4. XPath and SQL[ Go to top ]

    I don't think its a big deal, yes its a big change. But it really shouldn't be hard to update to use the latest. As long as there is a data migration path to JCR2 if possible, that would be the most important.
  5. Re: XPath and SQL[ Go to top ]

    As long as there is a data migration path to JCR2 if possible, that would be the most important.
    That's the easiest part.
    I don't think its a big deal, yes its a big change. But it really shouldn't be hard to update to use the latest.
    That's not the point (but I doubt it's true). They invent a new query language. That's a big deal!
  6. Re: JCR 2.0 under public review[ Go to top ]

    Wow, that's venturous!
    I am the same reaction, especially regarding XPath, but after looking at the Abstract Query Model (AQM) and its mapping to an object query model (JCR-JQOM), I think this moves will enable applications using JCR to build richer/more complex query features.
  7. Wow, that's venturous!


    I am the same reaction, especially regarding XPath, but after looking at the Abstract Query Model (AQM) and its mapping to an object query model (JCR-JQOM), I think this moves will enable applications using JCR to build richer/more complex query features.
    I think this is the intended way of looking at it. The abstract query model and the JQOM allows for query language parsers to be developed independently from the repository implementation. I am sure that for example the Jackrabbit community will certainly feature the XPath to JQOM parser that allows any application to keep using XPath on any JCR v2.0 compliant repository. In addition to that, additional parsers for languages like SparQL or Xquery can and will be developed in repository implementation neutral fashion. Personally, I find it important that we offer an abstract and precise description for the query facilities in a content repository that is not tied to any particular query syntax. I see it more of a convenience feature that we also specify an SQL mapping of the abstract query model, which allows a developer to use a string-based representation of their query out of the box. regards, david
  8. The abstract query model and the JQOM allows for query language parsers to be developed independently from the repository implementation.
    It is an excellent idea, and I believe many agree with me, what I do not agree is an implementation. Creating a home-grown-monster-query-language is wrong by design. There are enough well defined and mature query languages to choose from.
    I am sure that for example the Jackrabbit community will certainly feature the XPath to JQOM parser that allows any application to keep using XPath on any JCR v2.0 compliant repository.
    If XPath is out of the spec it does not matter if JR support is or not, it make application not portable.
    In addition to that, additional parsers for languages like SparQL or Xquery can and will be developed in repository implementation neutral fashion.
    I am doubting that it will be the case, as I sad before XQuery has rich features that will be hard to transform into proposed query API. And we can forget about an optimization ...
    Personally, I find it important that we offer an abstract and precise description for the query facilities in a content repository that is not tied to any particular query syntax.
    I see it more of a convenience feature that we also specify an SQL mapping of the abstract query model, which allows a developer to use a string-based representation of their query out of the box.
    Why target SQL persistent storage? Developers moving to JCR to abstract from DB. And JCR operates with nodes and properties that make XMLDB as a perfect fit and not RDBMS.
  9. I am the same reaction, especially regarding XPath, but after looking at the Abstract Query Model (AQM) and its mapping to an object query model (JCR-JQOM), I think this moves will enable applications using JCR to build richer/more complex query features.
    Well, the problem is not about finding the "better" query language, but it's one of credibility. JCPes are all about defining APIs that are meant to stay. That's why they're called "industry standards" in their finalized form. JSR-170 is hardly two years "on the market", and we see a significant part of its API, the query language, completely substituted. This happens on the user's expense. In fact, it might be considered bizarre the way JSR-170 defined its XPath support as a scratch list. But it still was relatively easy to comprehend, and, importantly, we could leverage our XML-XPath knowledge. Now, we have to learn yet-another-QL. No doubt, the JSR-283 expert group gave priority to implementation over API stability:
    The abstract query model and the JQOM allows for query language parsers to be developed independently from the repository implementation.
    As with many other IT standards bodies, software vendors are dramatically over represented in such expert groups. The JSR-283 group makes no exception to this rule. So it comes at little or no surprise that implementation issues become more important than API stability, as implementation is a natural vendor's headache. Sure, this aspect is important too, as we want as many vendors as possible to offer a JCR-API (especially level 1). But does this really take a completely new Query API? JSR-283 raises serious doubts about the future stability of the JCR API, and thus its credibility. Might we see in future releases, let's say with JSR-390 or so, a complete change of the node model, "because it's easier to implement"?? --Juerg
  10. Hi Juerg, I think you raise a very important point: We have to balance the ease of implementation and the requirements of the users of the API. I think in the case of query, it is very hard for vendors to go beyond what their existing repository indexes can do. In addition to that we also have a problem from a specification and documentation perspective. I tried to explain that here: http://www.nabble.com/The-rationale-behind-the-Abstract-Query-Model--was%3A-Xpath-deprecated--apache-tf4125364.html It is important to understand though that we very much value the stability of the interfaces and put a lot of effort behind backwards compatibility and will continue to do that (especially in future minor revisions). regards, david
  11. Re: JCR 2.0 under public review[ Go to top ]

    So what is wrong with XPath ? I thought that the next logical step would be to introduce XQuery instead or replacing XPath with some home-grown monster ...
  12. JCR is gaining acceptance in the market, with open source vendors like Alfresco, Apache, Magnolia as well as commercial vendors such as Day, and Percussions available.... The revision to the specification is an excellent step forward.
    It's surprising that major JCR implementations have not been able to provide a simple mechanism for user interface skinning and customization. For a UI designer's perspective on Java CMS systems, please see my article on JSFCentral.com. Trying to upload images and HTML into a number of floating windows is not very amusing when you are accustomed to working with professional tools like Adobe Dreamweaver, Flash and Photoshop that provide much more control over the presentation layer. I sincerely hope the JCR specification is enhanced to define a simpler UI customization strategy. I definitely think this should be part of the specification, and not left out as an "implementation detail". Ian Hlavats JSFToolbox - JavaServer Faces for Dreamweaver
  13. Re: JCR 2.0 under public review[ Go to top ]

    What does a JCR implementation have to do with the UI? A CMS system built on top of a JCR Repository. a "simpler UI customization strategy" should be part of a CMS spec (which I don't think there is one). Have you actually read JSR-170?
  14. Déjà vu[ Go to top ]

    It's surprising that major JCR implementations have not been able to provide a simple mechanism for user interface skinning and customization. For a UI designer's perspective on Java CMS systems, please see my article on JSFCentral.com.
    This must be a déjà vu.
    I sincerely hope the JCR specification is enhanced to define a simpler UI customization strategy. I definitely think this should be part of the specification, and not left out as an "implementation detail".
    Are you ok???
  15. Re: Déjà vu[ Go to top ]

    Hi Rex, Ok, I will stop promoting my article. Thanks for checking it out. :-) It was not meant as an in-depth review of the JCR market, just a summary of my experience evaluating many JSR-170 and JSR-168 implementations and my decision to go instead with JavaServer Faces and build my own Java content management system. (Incidentally, I'm using Jackrabbit as the JCR backend.) I am very interested in the Java portal and CMS space, but adoption is not practical for me since it means giving up familiar tools and techniques. If UI is not considered part of JSR-170 (as it stands now), then what is there to ensure that designers can change from one implementation to another without having to learn how to brand the user interface all over again? Skinning/customizing the UI is currently left as an implementation detail, which means there is no standardization on how to develop the UI of a JCR implementation. There is support for WEB-DAV and other access mechanisms, but this is not standardized and as a designer you cannot transfer your skills/experience from one particular product to another the way developers can. My point is simply that some standardization would be nice to benefit not only developers that use the JCR, but designers too. Ian
  16. Re: Déjà vu[ Go to top ]

    Ok, I will stop promoting my article. Thanks for checking it out. :-)
    :-)
    My point is simply that some standardization would be nice to benefit not only developers that use the JCR, but designers too.
    This is true. And so there is a powerful UI standard: The Road to Enlightenment