[dna-issues] [JBoss JIRA] Commented: (DNA-286) Implement namespace management

[Randall Hauch (JIRA)]

    [ https://jira.jboss.org/jira/browse/DNA-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12454831#action_12454831 ] 

Randall Hauch commented on DNA-286:
-----------------------------------

Thanks for catching this, Brian.  However, I think we are both right, which means that the namespace management aspects of JCR are more complicated.

Section 7.2.1 specifies the behavior for the workspace-level namespace registry, and specifically says "Attempting to re-assign a built-in prefix (jcr, nt, mix, xml or the empty prefix) to a new URI will throw a NamespaceException." Also, "Attempting to register a namespace with a prefix that begins with the characters 'xml' (in any combination of case) will throw a NamespaceException."  So I believe the JcrWorkspace and JcrNamespaceRegistry code as originally committed is in fact compatible with this aspect.

However, according to the JSR-170 specification, Section 6.3 defines the Session-level (local) namespace mapping behavior to be slightly different.  Firstly, the URI supplied to the session-level methods must already be registered globally (in other words, the session methods only change the prefix of a globally-registered URI).  Secondly, the session-level methods DO allow remapping any of the built-in namespaces to different prefixes (except for the default namespace URI).  Thirdly, the new prefix may not begin with the characters 'xml' (in any combination of case).  Fourthly, the default prefix (an empty string) may not be used as a new prefix.  Fifthly, there are some subtleties regarding remapping of existing URIs to prefixes that are already used in a mapping (for more, see section 6.3.3 of JSR-170).

Interestingly, the draft JSR-283 specification (Section 4.3.3) seems to have language that makes the session-level namespace mappings more usable.  It specifically states that when a session is acquired, the workspace-level namespace mappings are copied into the session (though Section 5.3.1 states that workspace-level changes are immediately reflected in all Sessions, unless they are overridden in those Sessions, making it seem like the Sessions do not actually get a true "copy").  It also seems to relax the restrictions on mapping URIs that already are mapping, and addresses the cases when mappings are removed but are still needed (they are re-added, but using a different generated prefix so as to not clash with any workspace-level generated prefixes).  The draft JSR-283 specification seems to no longer require that the URI in the session-level mappings must already exist in the global mappings.

Suffice to say that the Session-level namespace management needs a little work.  We'll have to identify whether JSR-283 is indeed relaxing any behavior of JSR-170, and if so, whether those changes are better.  (Generally, I'd say we want to implement JSR-170, but the wording of JSR-170 in this case seems to have some major issues by only working with existing URIs.)  Hopefully the specs are not in conflict.

> Implement namespace management
> ------------------------------
>
>                 Key: DNA-286
>                 URL: https://jira.jboss.org/jira/browse/DNA-286
>             Project: DNA
>          Issue Type: Sub-task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-286.patch
>
>
> Our JCR implementation needs a namespace registry that stores the namespaces and their prefixes in such a way that they can be clustered.  The best approach is probably to store the namespaces under "/jcr:system/" in a DNA-specific location (as the JCR spec does not specify that the namespaces are available as content.  By doing this, the namespace registry would automatically work across a cluster (any clients that are using the same RepositorySource).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira