Title: [xri] [star syntax issue] Clarifying the argument
This doesn't make sense to me. The rules
for relative resolution of URI segments is based on the following criteria:
1) Presence of the segment delimiter
character at the start of a relative URI, e.g., "/abc"
2) Absence of the segment delimiter
character at the start of a relative URI, e.g., "abc".
Why would the rules for relative
resolution of XRI subsegments be any different, i.e., be based on anything
except presence or absence of the subsegment delimiter character?
You mention that "/:1234" could
mean "the same thing" (I assume that means "the same thing as a relative
subsegment"). That can't be true if "/:1234" can also mean a
relative segment, as it does today in XRI 1.0 syntax. Then an application
wouldn't be able to distinguish between a relative segment and a relative
subsegment.
It is of course possible that we could
introduce another character (different than the persistence decorator character,
or else you run into the original problem described in my message) to be the
prefix character for a relative subsegment. But why would we do that to make XRI
syntax even more complicated when the obvious rule, per the pattern established
by URI syntax, is to use the presence or absence of the subsegment delimiter
character?
=Drummond
From: Dave McAlpin
[mailto:]
Sent: Tuesday, August 03, 2004 8:14 PM
To: Drummond Reed;
Subject: RE: [xri] [star syntax
issue] Clarifying the argument
They fact that the syntax *:1234 means
"resolve this relative to a subsegment, not a segment" is arbitrary.
There's no reason ;:1243 or .../:1234 or some other combination of characters
couldn't mean the same thing. I don't think relative subsegment resolution
has any bearing on the star syntax issue.
From: Drummond
Reed [mailto:]
Sent: Tue 8/3/2004 9:35 PM
To:
Subject: [xri] [star syntax issue]
Clarifying the argument
[Note: on the XRI Editor's SC call today, it was
agreed that Dave McAlpin,
Mike Lindelsee, Fen Labalme, and myself would take point on trying to come
to closure on the star syntax issue, explained in an earlier post today (see
http://lists.oasis-open.org/archives/xri/200408/msg00006.html).
We also
agreed that as much of this discussion as feasible would take place on the
list. If any telecons are needed, we'll post minutes to the list. For
filtering purposes, we will try to prefix the subject lines of all messages
on this thread with "[star syntax issue]". =Drummond)
This first message is clarify that the writeup posted earlier today
(http://lists.oasis-open.org/archives/xri/200408/msg00006.html)
was not
meant on its face to propose new relative resolution rules for XRIs. Dave is
correct in his message below that, as discussed on the XRI Editor's SC call,
it may result in our decision to define a new relative resolution algorithm
for subsegments in XRI 1.1.
However the key point of the argument in the original posting was that if we
do not separate the roles of subsegment delimiter and persistence decorator
into two separate syntactic characters in XRI 1.1 syntax, then we preclude
the ability of any application using XRIs to define its own relative
subsegment resolution rules, e.g., rules that can differentiate between:
a) persistent relative XRIs that are relative to the current node, e.g.,
":123", and
b) persistent relative XRIs that may be relative to some higher subsegment,
e.g., "*:123" (if star is the subsegment delimiter character and
colon the
persistence decorator.)
If the only syntax available for expressing relative persistent subsegments
is ":123", we have precluded applications from being able to do (b)
above.
This would effectively be the same as URI syntax defining that ":123"
and
"/:123" are equivalent. If that was the case, it would be impossible
to have
resolution rules that were different for ":123" and
"/:123".
So it is not an issue of whether we need in XRI 1.1 to extend URI relative
resolution rules by defining relative subsegment resolution rules (which we
may or may not decide to do.) The issue at a syntax level is whether ANY
application that uses XRIs may EVER want to define such resolution rules.
Even if XDI did not exist today (and have a clear and compelling need to use
relative subsegment resolution rules immediately), the effect of not
separating the syntax character used to delimit subsegments from the syntax
character used to indicate ("decorate") a persistent subsegment would
preclude this capability in any future application.
Does this argument leave any question that we must separate these roles in
XRI 1.1?
=Drummond
-----Original Message-----
From: Dave McAlpin [mailto:]
Sent: Tuesday, August 03, 2004 3:47 PM
To: Drummond Reed;
Subject: RE: [xri] XRI 1.1 issue: star syntax semantics
It's too late to respond to the technical issues here before the call,
but I think we need to address the proposed requirement for relative
resolution of subsegments before we modify syntax to support it.
1) Should we consider a new relative resolution algorithm for
subsegments?
2) If we should, what are the rules? Just a list of examples would be
instructive.
3) How do we reconcile these rules with relative resolution as defined
by 2396bis? In other words, if a non-XRI aware processor applies
standard resolution rules, is the result equivalent to the rules
proposed in 2? If not, what are the implications for URI compatibility?
I think we need to address these issues independently before we suggest
that we've somehow demonstrated that * must be a separator.
Dave
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php.
