[
https://issues.apache.org/jira/browse/JCR-5140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-5140:
--------------------------------
Description:
There are a few use cases where a new namespace prefix needs to be computed for
a given namespace name (this list may not be exhaustive):
- when mapping expanded names to JCR names when the namespace name (URI) is
not known in the repository (yet) - though that's a use case not supported in
Oak, creating of new items with previously non-registered namespace is not
possible
- when importing content where namespace names (URIs) are known, but prefixes
may be not
- when looking up a name from the repository from a repo that persists names
with prefixes, but the prefix is already locally mapped to a different namespace
- when registering node types where the namespace name (such as defined in the
CND) is new, but the "preferred" prefix is already in use) - note that this
requires write access to the repository's namespace registry
Automatically generating the prefixes has several commons problems:
- consistency: generating prefixes in different places and/or based on
previous state of the registry (such as by incrementing counters until new
non-conflicting prefix found) causes prefix inconsistency across systems for no
good reason
- conciseness and readability: for certain namespaces, there are commonly used
prefixes (such as in DC, XMPP etc), and it would be good to just use those when
possible
Proposal: have a single place that offers help for generating prefixes (this
ticket is in JCR space as jackrabbit-jcr-commons already has NamespaceHelper,
but of course the location can be discussed). -We may want to start in
oak-commons, so that we can more quickly iterate in Oak, and then maybe later
move this into JCR commons.-
Blue print:
{code:java}
// Suggests a prefix for the given namespace, based on
// well-known XML namespaces, or alternatively derived
// from the namespace name.
public static String suggestPrefix(String namespace);
// as above, but will take exisiting prefixes into account
// this would be for the case where the prefix already exists
// but is mapped to a different namespace name.
// Lookup for existing prefix so that we can abstract out the
// actual JCR interface (to be discussed)
public static String suggestPrefix(String namespace, Function<String, String>
getNamespaceForPrefix);
// maybe more helpers:
public static boolean isValidNamespace(String namespace);
public static Map.Entry<String, String> extractPrefixAndNamespace(String
jcrName, Function<String, String> getNamespaceForPrefix);{code}
We'd also need a hook to account for "internal", unless we want to hard-wire
that into this.
was:
There are a few use cases where a new namespace prefix needs to be computed for
a given namespace name (this list may not be exhaustive):
- when mapping expanded names to JCR names when the namespace name (URI) is
not known in the repository (yet) - though that's a use case not supported in
Oak, creating of new items with previously non-registered namespace is not
possible
- when importing content where namespace names (URIs) are known, but prefixes
may be not
- when looking up a name from the repository from a repo that persists names
with prefixes, but the prefix is already locally mapped to a different namespace
- when registering node types where the namespace name (such as defined in the
CND) is new, but the "preferred" prefix is already in use) - note that this
requires write access to the repository's namespace registry
Automatically generating the prefixes has several commons problems:
- consistency: generating prefixes in different places and/or based on
previous state of the registry (such as by incrementing counters until new
non-conflicting prefix found) causes prefix inconsistency across systems for no
good reason
- conciseness and readability: for certain namespaces, there are commonly used
prefixes (such as in DC, XMPP etc), and it would be good to just use those when
possible
Proposal: have a single place that offers help for generating prefixes (this
ticket is in JCR space as jackrabbit-jcr-commons already has NamespaceHelper,
but of course the location can be discussed). We may want to start in
oak-commons, so that we can more quickly iterate in Oak, and then maybe later
move this into JCR commons.
Blue print:
{code:java}
// Suggests a prefix for the given namespace, based on
// well-known XML namespaces, or alternatively derived
// from the namespace name.
public static String suggestPrefix(String namespace);
// as above, but will take exisiting prefixes into account
// this would be for the case where the prefix already exists
// but is mapped to a different namespace name.
// Lookup for existing prefix so that we can abstract out the
// actual JCR interface (to be discussed)
public static String suggestPrefix(String namespace, Function<String, String>
getNamespaceForPrefix);
// maybe more helpers:
public static boolean isValidNamespace(String namespace);
public static Map.Entry<String, String> extractPrefixAndNamespace(String
jcrName, Function<String, String> getNamespaceForPrefix);{code}
We'd also need a hook to account for "internal", unless we want to hard-wire
that into this.
> Improve support for generating namespace prefixes
> -------------------------------------------------
>
> Key: JCR-5140
> URL: https://issues.apache.org/jira/browse/JCR-5140
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-jcr-commons
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Major
>
> There are a few use cases where a new namespace prefix needs to be computed
> for a given namespace name (this list may not be exhaustive):
> - when mapping expanded names to JCR names when the namespace name (URI) is
> not known in the repository (yet) - though that's a use case not supported in
> Oak, creating of new items with previously non-registered namespace is not
> possible
> - when importing content where namespace names (URIs) are known, but
> prefixes may be not
> - when looking up a name from the repository from a repo that persists names
> with prefixes, but the prefix is already locally mapped to a different
> namespace
> - when registering node types where the namespace name (such as defined in
> the CND) is new, but the "preferred" prefix is already in use) - note that
> this requires write access to the repository's namespace registry
> Automatically generating the prefixes has several commons problems:
> - consistency: generating prefixes in different places and/or based on
> previous state of the registry (such as by incrementing counters until new
> non-conflicting prefix found) causes prefix inconsistency across systems for
> no good reason
> - conciseness and readability: for certain namespaces, there are commonly
> used prefixes (such as in DC, XMPP etc), and it would be good to just use
> those when possible
> Proposal: have a single place that offers help for generating prefixes (this
> ticket is in JCR space as jackrabbit-jcr-commons already has NamespaceHelper,
> but of course the location can be discussed). -We may want to start in
> oak-commons, so that we can more quickly iterate in Oak, and then maybe later
> move this into JCR commons.-
> Blue print:
> {code:java}
> // Suggests a prefix for the given namespace, based on
> // well-known XML namespaces, or alternatively derived
> // from the namespace name.
> public static String suggestPrefix(String namespace);
> // as above, but will take exisiting prefixes into account
> // this would be for the case where the prefix already exists
> // but is mapped to a different namespace name.
> // Lookup for existing prefix so that we can abstract out the
> // actual JCR interface (to be discussed)
> public static String suggestPrefix(String namespace, Function<String, String>
> getNamespaceForPrefix);
> // maybe more helpers:
> public static boolean isValidNamespace(String namespace);
> public static Map.Entry<String, String> extractPrefixAndNamespace(String
> jcrName, Function<String, String> getNamespaceForPrefix);{code}
> We'd also need a hook to account for "internal", unless we want to hard-wire
> that into this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
