OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]