On 2013-10-02 16:29, Jukka Zitting wrote:
Hi,
On Tue, Oct 1, 2013 at 10:31 AM, Julian Reschke <[email protected]> wrote:
Well, the call could either fail (in which case the client would have a hard
time to figure out how to proceed), or it can pass (and the returned node
would "know" its name).
I think I'd prefer the latter.
Only if you're already prepared to deal with such changes. If you're
not, I think it'll be clearer to fail fast (with a good enough
explanation in the exception message) than to silently normalize
content and possibly cause subtle issues down the line when the
content doesn't match exactly what the client originally created.
That's why it's bad that the spec is silent on it.
1) Is this something the spec needs to say?
I'd rather leave it up to the implementations. I think the spec is
already vague enough to allow different interpretations.
2) Is this something we want to do in Jackrabbit?
I wouldn't mind adding a validator that refuses to accept
non-normalized names, though something like that would need be
configurable to prevent backwards compatibility issues.
I just tested OSX WebDAV access to Jackrabbit, and it uses NFD. So if we
turn a check on, we'll also have to figure out how and where to map.
3) Or in Oak?
Unless there's a good reason to do otherwise, Oak and Jackrabbit
should behave the same way by default. So if we add this in
Jackrabbit, we should do so too in Oak.
Note that adding such a normalization validator is quite easy in Oak;
just insert a new Validator instance that checks all names for
normalization.
Best regards, Julian
