[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Potential breakthrough
>>> Wil wrote: >>> >>> 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 wrote: >> >> Just to clarify, it's a "global-xref is >> n-subseg-XRI-where-first-subseg-is-GCS construct". >> > >Wil wrote: >How so? Without sticky stars and bangs, wouldn't the global-xref in >@foo+bar*baz be just "+bar"? [=Drummond] Agreed. I haven't had time to do the ABNF yet, but I think you're right, global-xref would just be a single subsegment. >A related question which I don't think was answered: do we support >relative subsegments? I.e. can you have @foo refer to @foo*bar by just >"*bar"? [=Drummond] You've asked that question before, and it's a really good one. My gut says yes, that *subsegments and !subsegments should be relative to other absolute XRI authorities (i.e., *west or !1234 would be relative to @ootao, @ootao*office, and =drummond). But we need to think this through. >If so, we wouldn't have the ability to reference a global-xref >relatively because there is no LCS (* or !) in the absolute reference, >i.e. @foo cannot refer to @foo+bar just by saying "+bar" because it >could be mistaken as an absolute reference. [=Drummond] Not "mistaken" -- +bar *is* an absolute reference. In fact we've never had the ability to reference a global-xref relatively because that's the whole point of it -- it's an absolute identifier by itself. In other words, XRI lets you join two or more absolute XRIs into another absolute global XRI, whereas with URIs, you can only join a relative URI to an absolute URI (the base URI) to create another absolute URI. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]