[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Another perspective on GCS star issue
Further reflection on the "star optional after a GCS character" issue on the XRI Editor's SC call yesterday has produced two additional perspectives I believe may be helpful. Since I'll be on the road for tomorrow's XRI Editor's SC call, I'll post these thoughts here so folks can review them before the call. The first perspective is based on overall treatment of null segments in XRI syntax; the second based on overall treatment of first subsegments. OVERALL TREATMENT OF NULL SUBSEGMENTS So far in XRI 1.1 we've made three decisions relative to null subsegments: 1) Generic XRI syntax should allow null subsegments, for the same reasons that RFC2396bis does (and because they are required by at least one XRI application, XDI.) 2) The XRI authority portion of an XRI, where we have an interest in tighter syntactic rules in order to support reliable XRI resolution, should as a rule not allow null subsegments. 3) The one exception is null subsegments after a GCS character in order to allow a persistent subsegment delimiter ("!") to follow a GCS character. It is #3 that leads to the issue we are discussing, namely: should we also allow a * null subsegment after a GCS character, and if so, what does it mean? The perspective that comes from looking at the overall issue of null subsegment significance in XRIs is this: from the standpoint of generic XRI syntax, a null subsegment MUST be treated as significant in an XRI path, because applications like XDI are counting on this behavior. For example, the following two XRIs MUST NOT be considered equivalent: @foo/bar @foo/*bar In XDI, these would address completely different resources. Thus the significance of the star as a null subsegment delimiter is critical to XDI addressing. It would be consistent with this rule to say the presence of a null subsegment in an XRI authority MUST also be treated as significant. This is also consistent with rule #2 above about why we do not allow null subsegments in an XRI (because if they were present they would be significant.) The logical conclusion is that if we allow null subsegments after a GCS character before a * delimiter, the null subsegment MUST be considered significant. That would mean that the following would not be equivalent: @foo @*foo However we were in a agreement on yesterday's call that if @*foo were allowed, it should be equivalent to @foo. OVERALL TREATMENT OF FIRST SUBSEGMENTS A second perspective on this issue comes from the overall XRI treatment of first subsegments. In XRI 1.0, we defined that the first subsegment in a segment was reassignable by default if it was not preceeded by a persistent subsegment delimiter, because that's the way URIs and file paths and many other path-based addressing systems already worked. So in "/foo/bar", "foo" and "bar" were both reassignable by definition. We applied the same rule to GCS characters for the same reason: it made them as simple and human-friendly as possible, and the behavior was consistent with "//" in URI authorities. Conclusion: since the rule for ALL segments in an XRI is that the first subsegment is reassignable unless preceeded by a persistent subsegment delimiter, there is no need to add a * to indicate reassignability. CONCLUSION
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]