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