1 of 1 people found this helpful
This is expected behavior. Per the JSR-283 specification, the "" prefix is permanently mapped to the "" URI. Your file is attempting to map the "" prefix (in XML) to a different URI than the blank one prescribed by the JCR spec, and thus ModeShape throws an exception.
Here's the relevant text in the Section 11.1 of the spec:
1. For each XML namespace declaration with prefix P and URI U:
a. If the namespace registry already contains a mapping of some prefix P' to U (where P' may or may not be equal to P) then the namespace registry is left unchanged.
b. If the namespace registry does not contain a mapping to U then such a mapping is added to the registry. The prefix assigned may be P, if P is not already used in the registry, otherwise the repository must generate and assign a new, previously unused, prefix.
Unfortunately, we're not generating a new, previously unused prefix in this case.
You could log an issue for this.
BTW, I think a workaround might be to pre-define the namespace ("http://www.ns.com/" in your case) in the workspace registry. The importer should find that prefix and use it for the namespace. This isn't an ideal workaround, but I think it would work.
I have tried the workaround by pre-registering the namespace (same URI) in the workspace registry before the XML file is imported, but I still get the same error, telling that the empty prefix is already permanently mapped. According to the spec, when the import processes the xmlns="<URI>" declaration, since the URI is already mapped to a different prefix (the one I used for the explicit registration), it should leave the namespace registry unchanged. So, is there a specific processing dedicated to the empty prefix, or is this just a JCR compliance issue?
Anyway, I guess that the only available solution is to force users to write XML documents that do not contain a default namespace declaration. Do you confirm?
Thank you very much for your answer, Randall.
Rats. I wish there was a workaround.
Either way, can you please log an issue? We can and should fix the behavior. The only downside is that, without a workaround, you'll have to wait until the 3.1.2 release before it works like you want.
First of all, the XML document you supplied is not valid. Recall that XML files imported via the JCR API must conform to the Document View or System View formats defined in the JSR-283 specification.
Your XML document is closer to the Document View format, but the correct representation would be:
<?xml version="1.0" encoding="utf-8"?>
<childNode jcr:primaryType="nt:unstructured" prop1="value1" />
After the namespace bug is fixed (in MODE-1795), a new namespace will be registered with the URI of "http://www.ns.com" and a generated prefix. (The prefix is generated because the XML namespace prefix is "", but that's already mapped in the repository's namespace registry. Therefore, the implementation is expected to create a new prefix.) Importing this XML file will create a new node named "ns001:childNode" (where "ns001" is whatever the registered namespace is upon registration) of type "nt:unstructured" with a single property "ns001:prop1". Note that the node and property names are chosen based upon the XML namespace. Thus, if you want the names to not have prefixes, you need to define an XML namespace with an empty URL (which IIRC is accomplished by not defining the default namespace).
Of course, you can define any properties and any children on any of the nodes; the above is just an example. Also, the System View format is more expressive (though much more verbose and difficult to read) and is the only way to really handle multi-valued properties. It is a known issue with the JCR specification that the Document View format cannot handle multi-valued properties.