[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [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:Dave.McAlpin@epok.net] Sent: Tuesday, August 03, 2004 3:47 PM To: Drummond Reed; xri@lists.oasis-open.org 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]