On 10 Nov 2004, at 10:09 pm, Roy T. Fielding wrote:
On Nov 10, 2004, at 4:34 AM, Graham wrote:On 10 Nov 2004, at 8:20 am, Roy T. Fielding wrote:
Because that is what the proposal formerly said, before it was simplified
by removing that feature.
How is it a simplification? Let's code it (in Cocoa):
Do you seriously expect me to evaluate simplicity based on whether or not a system library function already exists in Cocoa?
My point is that before the simplifcation, it was possible to get to the final relation-URI with a single function call that surely exists in every URI-aware system library. Very elegant.
Either:
NSURL *baseURL=[NSURL URLWithString:@"http://www.iana.org/assignments/relation/";];
NSURL *relationURL=[NSURL URLWithString:rel baseURL:baseURL];
vs
NSURL *relationURL;
if ([rel rangeOfString:@":"].location==NSNotFound) {
relURL=[NSURL URLWithString:[@"http://www.iana.org/assignments/relation/"; stringByAppendingString:rel]];
} else {
relURL=[NSURL URLWithString:rel];
}
Or you could just use the first one for both.
No you can't. The proposal allows for relation names to be registered that include dots and slashes. If one of those were treated as relative URI it would come up with a different result to appending.
OK, I get that there aren't any valid relative URI refs that aren't part of the registry, so I get your motivation for the change. It doesn't actually lead to a simplification of the spec or the code in any language that has URL classes.
It does in any code that is smart enough to just treat them as strings. Just because you have URL classes doesn't mean you have to use them.
Since the proposal doesn't say what comparison method should be used (a big omission btw), deferring to the URI class and it's isEqual: method seems the only prudent thing to do.
Graham
smime.p7s
Description: S/MIME cryptographic signature
