jsr-283
  1. jsr-283
  2. JSR_283-506

making abstract JCR names less abstract

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: general
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      506

      Description

      The JCR APIs have always been plagued by the session-dependance of prefixed
      names, as it makes it impossible to define constant values for things named
      using JCR names.

      Examples include immutable node names (jcr:content), node and property type
      names, and, more recently, privileges (see issue 468).

      During the Costa Mesa F2F, the consensus apparently was to consider this a
      client convenience issue, and thus worry about it in JCR 2.1.

      I believe it would be worthwhile to solve this earlier.

      There are two obvious way to represent abstract JCR names in Java:

      1) Using a new class/interface "Name" (with getters for namespaceURI and local
      name),

      2) Using James Clark's notation ("expanded name") as a String:
      "

      {namespaceuri}

      localname".

      Discussion:

      1)

      + clean approach

      • requires additional method signatures

      2)

      + simple approach, avoids some of the new method signatures (in parameters)

      • there may be a few edge cases where a given String can both be a prefixed name
        and an expanded name.

      My preference would be 1), introducing javax.jcr.JcrName, and to add support for
      JcrNames in addition to prefixed strings in those places where it provides the
      most value.

      1. NameParser.java
        4 kB
        reschke
      2. NameParser.java
        3 kB
        reschke

        Issue Links

          Activity

          Hide
          reschke added a comment -

          I've attached a trial implementation; it seems to be possible to parse it properly.

          This needs more eyes and test cases though.

          Show
          reschke added a comment - I've attached a trial implementation; it seems to be possible to parse it properly. This needs more eyes and test cases though.
          Hide
          Peeter Piegaze added a comment -

          Clarified that paths may contain extended names.

          Show
          Peeter Piegaze added a comment - Clarified that paths may contain extended names.
          Hide
          reschke added a comment -

          The grammar in 3.3.4 doesn't help in parsing a lexical path, because it's ambiguous.

          We should state that, and also add instructions how to reliably parse a path.

          The fact that we couldn't agree about the best way to do it in Jackrabbit
          (https://issues.apache.org/jira/browse/JCR-1712) sort of shows it needs to be
          stated in the spec; otherwise we'll get interop problems.

          Show
          reschke added a comment - The grammar in 3.3.4 doesn't help in parsing a lexical path, because it's ambiguous. We should state that, and also add instructions how to reliably parse a path. The fact that we couldn't agree about the best way to do it in Jackrabbit ( https://issues.apache.org/jira/browse/JCR-1712 ) sort of shows it needs to be stated in the spec; otherwise we'll get interop problems.
          Hide
          Peeter Piegaze added a comment -

          As decided in the 23 February phone conference:

          Parsing of paths must be independent of the state of the repository. In particular, the parser should not
          distinguish between namespaces currently registered in the repository and those that are not.

          Show
          Peeter Piegaze added a comment - As decided in the 23 February phone conference: Parsing of paths must be independent of the state of the repository. In particular, the parser should not distinguish between namespaces currently registered in the repository and those that are not.
          Hide
          Peeter Piegaze added a comment -

          Fixed: Guidance added about parsing in new section 3.3.4.1 Parsing Lexical Paths

          Show
          Peeter Piegaze added a comment - Fixed: Guidance added about parsing in new section 3.3.4.1 Parsing Lexical Paths

            People

            • Assignee:
              jsr-283-issues
              Reporter:
              reschke
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: