[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Potential breakthrough
Wil, see [=Drummond] inline. -----Original Message----- From: Tan, William [mailto:William.Tan@neustar.biz] Sent: Wednesday, May 02, 2007 9:19 AM To: Drummond Reed Cc: xri@lists.oasis-open.org Subject: Re: [xri] Potential breakthrough Drummond Reed wrote: > > I have an internal maxim that I follow: if Steve tells me he's got a > problem with something, and after three times trying to work it out > with him, he's still got a problem with it, then I need to look at it > very closely and see if there's a better solution. > > I've worked long enough with Marty now to realize the same thing is > true with him. > > So when both of them plus Wil are telling me something is too complex, > that's one helluva strong signal. > Not to mention Gabe too. [=Drummond] That goes without saying ;-) > So after yesterday's thread, I looked closely at the requirements > again and thought about the key issue Steve has raised about how > "sticky stars" makes for funky synonym rules. This jibes with what > Marty keeps saying about how the original "compact syntax" was much > simpler than "sticky stars". > > I have always been the one saying that we needed sticky stars. So I > revisited that assumption.and realized that in that area I too had > been stuck with a "2.0" filter on. I had been assuming that anything > you could express as a parenthetical xref (which is "opaque" to XRI > resolution) had to be something that was also equally "opaque" when > expressed as a global-xref. > > But it's that assumption that leads both to most of the increased > complexity and the funky synonym problem. So if you drop that > assumption and do as Marty has been suggesting all along and simply > treat all subsegments as subsegments. > > .everything works just fine. > [snip] > > So I tried to figure out if there was any other requirement - in XDI > RDF or anywhere else global-xrefs would be used - that would not be > met if global-xrefs were not opaque. I couldn't come up with any. > I think you said that if we couldn't have sticky stars it would hugely diminish the benefits of concatenated syntax. I don't recall drilling into the reasoning behind that. [=Drummond] I want to be totally upfront about this: I *was* the one who said that. Multiple times. And it was because I had it stuck in my head that global-xrefs needed to be opaque like parenthentical xrefs. But after the kick upside the head yesterday, I drilled down into my own reasoning behind that...and found an empty well. (In fact, it kept me up an extra hour last night because the more I thought about it, the more I thought non-opaque global-xrefs were really much simpler and more useful. I began to wonder why I had been stuck on opaqueness so long. Mea culpa.) I agree that not having the sticky star rules does simplify things a lot. In effect, we're kind of back to compact syntax, which means that a global-xref is a two-subseg-XRI-where-first-subseg-is-GCS construct. [=Drummond] Just to clarify, it's a "global-xref is n-subseg-XRI-where-first-subseg-is-GCS construct". In this case, it really becomes more like a shorthand i.e. compact syntax. I wonder if this approach was taken if we should revisit normalization? Certainly, the rules of when to normalize to a parenthesized form are going to be simpler as well. I still feel that the parentheses makes it clear that the referenced identifier is local, especially Steve and Marty's point that =steve@microsoft.com gives a false sense impression that the real authority is @microsoft.com to people who are used to email identifiers. [=Drummond] NO NO NO NO NO!!! First, just on the parens issue: I think we've gone over it ad infinitum that global-xrefs are NOT local-xrefs, that normalization would destroy the WYSIWYG rule, and that it adds complexity where we least need it. Secondly, on the email-address-confusion issue (which I did not address in yesterday's email because there were bigger fish to fry): the whole point of the MXRI proposal (on http://wiki.oasis-open.org/xri/XriCd02/FormsAndTransformations) is to enable an XRI to be expressed as a legal RFC 2822 email address. Yes, there will be people who mistakenly believe that the @ component is the authority. But that's one of the inescapable roadbumps of backwards compatability. For example, there are definitely people who think that all HXRIs that use the xri.net proxy server are URLs controlled by XRI.net. That's a byproduct of us working out backwards compatability with URL syntax. Does that mean we should through out HXRIs? I'm as strong an advocate of MXRI syntax as ever because the use cases for XRIs as messaging endpoints are increasing almost every day. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]