RE: [xri] [star syntax issue] Clarifying the argument

Title: [xri] [star syntax issue] Clarifying the argument

Actually I suggested .../abc 
(i.e. three dots instead of two) but you're right, that doesn't make much sense. 
I'd actually expect relative resolution of subsegments to follow the same 
pattern as relative resolution of segments. I worked out a table based on 
the examples in 2396, but they'll be hopeless in email. Take a look at http://xrixdi.idcommons.net/moin.cgi/XriChangeRelativeResolutionForSubsegments to 
see what it might look like.

 

From: Drummond Reed 
[mailto:]
Sent: Wed 8/4/2004 1:11 
AM
To: 
Subject: RE: [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.