RE: [xri] XRI Resolution 2.0 Draft 09 comments

["Tan, William" <William.Tan@neustar.biz>]

 

1. xrd:XRD/xrd:Service/xrd:Pattern – what flavor of regular expression should the value be (perl-compatible, posix, etc.)? Is the full power of regexp really required, why not just simple string comparison or prefix matching?

 

### Great question. Dave was the original proposer of this feature – I'll let him answer (others, please chime in on this.) I know you're working on very high-volume HTTP proxy resolvers – what's your view of the best tradeoff between comparison functionality and performance? ###

 

[Wil] I have 3 points of concern:

 

a) Performance-wise, because the number of regular expressions to compile equals the number of Pattern tags (as opposed to a single pattern matched against multiple candidates), it may be expensive for proxy resolvers.  However, I don’t have concrete statistics to prove my point.

 

b) If a regexp is valid but contains a logic error, there is no way for the registry to verify.

 

c) Standard – which flavor of regular expression to use? Various regular expression libraries support different options. If we support regular expressions, users might ask: how to specify case insensitive match? How to do negation? Are Unicode character properties (\p & \P) supported?

 

 

4. Section 2.8 Versioning - if the version attribute is optional, implementations may take the shortcut to ignore its presence thereby defeating the purpose of versioning. A newer version may not change the schema but we may want the possibility of modifying the semantics of the elements or attributes. We may not have that choice should implementations do not respect version information.

 

### Good point. So you believe it should be required. Gabe? Dave? ###

 

[Wil] I believe the schema specifies that 2.0 is the default value when the version attribute is omitted. It’s probably sufficient to specify that clients SHOULD verify the supported major version number when processing XRDs.

 

 

6. Section 3.2.7 – What’s the difference between <Synonym xref=”true”> and <XSynonym>?

 

### That's an error – holdover from an interim revision. <XSynonym> replaced the proposal for <Synonym xref=”true”> (adding an explicit element was judged easier than having to parse an attribute).

 

[Wil] Aren’t we overloading the meaning of XSynonym? If I read it correctly, XSynonym contains an XRI reference that can be combined with the remaining unresolved subsegments only if no sibling Service elements are returned.