> I think that the would initially setup his namespaces to be mapped on a session basis to
> whatever makes sense for the application and then use literals throughout the application.
> With respect to the isNodeType() I would then expect it to fail without an exeception
> specific to the unknown prefix
The client should have received a NamespaceException already when trying to setup the "foo" prefix in this case, so I still think it's good form to throw an exception from isNodeType() when encountering an unknown prefix.
> I guess from an application perspective I would even assume a getItem("/unknownprefix:bar")
> to throw a PathNotFoundException.
Without a preceding Session.setNamespacePrefix() call the repository has no way of knowing which namespace the client is referring to with "unknownprefix". There could well be a node "/
bar" that the client actually was trying to locate. If the method call allowed a full namespace, then I think a PathNotFoundException would be appropriate (much like I originally proposed in
JCR-472 for invalid UUID strings), but since the repository can't tell what the client is really referring to, throwing a NamespaceException (or a more generic RepositoryException) is IMHO the right thing to do.
> basically i think that a client that does not map its namespaces on a per session basis is broken.
> From my perspective I would assume that once the namespaces are mapped, I would like to work
> in my application code using "static/hardwired"-prefixes only. I think that this makes the code much
> more readable.
Agreed, and this actually avoids the whole problem here.
Unfortunately the JSR 170 Session.setNamespacePrefix() is rather limited, making correct namespace remapping a rather complex process. Thus I believe that many applications simply assume a static set of namespace mappings and leave the details up to the administrator. JSR 283 is addressing this issue.