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. > 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. > 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. BR, Jukka Zitting
