[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRI Resolution 2.0 Draft 09 comments
|
From: Tan, William
[mailto: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? [Drummond] All good questions. From your vantage, engineering a very
highly-scalable XRI proxy resolver, what compromise do you recommend to
minimize the impact and load on proxy resolvers while maximizing the utility of
the Pattern element for selecting Service endpoints? 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. [Drummond] So do you recommend that we make the version attribute
required for the xrd:XRD element? 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. [Drummond] Not quite. Like Synonym, XSynonym contains
an XRI reference that identifies the same resource as the Query XRI. The only
difference between Synonym and XSynonym is that the latter is NOT assigned by
the authority for the XRD, but by some other authority (whereas a Synonym is
assigned by the authority for the XRD). So for any XRD, the Query XRI, any Synonym
XRIs, and any XSynonym XRIs all identify the same resource, and all Service
elements in that XRD apply to that identified resource. The special thing about XSynonyms are that
IF you get an XRD with an XSynonym and no Service elements, the XSynonym gives
you an alternative resolution path, which we call an XRI redirect. Essentially
it means, "start again with this new XRI from a different authority".
Note that a Synonym doesn't give you this option because it will return the
same XRD you have already. Hope that helps. =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]