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: RE: [xri] Issue 1: Clarifying * Semantics


First, there is a difference of opinion that "the
difference between the two options we are discussing
is negligable" when it comes to the simplicity of XRI
parsing. I invite other implementers to comment on the
simplicity of parsing two vs. three XRI separator
characters.

On the second point, it is absolutely unacceptable to
require all human-friendly, reassignable XRIs to
include the star character. That would directly
conflict with the requirement of human-friendly,
reassignable XRIs being as simple and easy to remember
as possible.

=Drummond


--- Dave McAlpin <Dave.McAlpin@epok.net> wrote:
&gt; As we've pointed out before, the thing that makes
&gt; parsing and
&gt; interpreting XRIs difficult is cross-references.
The
&gt; difference between
&gt; the two options we're currently discussing is
&gt; negligible.
&gt; 
&gt; As for simplification of the rules, if implied *
is
&gt; confusing let's just
&gt; require it. In other words, keep the current
&gt; interpretation of * and
&gt; change xri:@example/foo to xri:@*example/*foo,
&gt; comparable to xri:@:3/:4.
&gt; This is a much simpler change and has the
benefits
&gt; you mention below.
&gt; 
&gt; Dave
&gt; 
&gt; &gt; -----Original Message-----
&gt; &gt; From: Drummond Reed
&gt; [mailto:drummond.reed@cordance.net]
&gt; &gt; Sent: Wednesday, July 07, 2004 5:12 PM
&gt; &gt; To: Wachob, Gabe; Loren West;
&gt; xri@lists.oasis-open.org
&gt; &gt; Subject: RE: [xri] Issue 1: Clarifying *
Semantics
&gt; &gt; 
&gt; &gt; As one of the proponents of this proposal
(who is
&gt; &gt; finally getting caught up with his vacation
&gt; email),
&gt; &gt; I'll accept Gabe's invitation to speak up
about
&gt; it.
&gt; &gt; 
&gt; &gt; I don't believe this change is "aesthetic"
(I
&gt; agree an
&gt; &gt; aesthetic change could be argued ad
infinitum
&gt; either
&gt; &gt; way.) It is functionally motivated by the
&gt; following
&gt; &gt; reasons:
&gt; &gt; 
&gt; &gt; 1) Having a single second-level separator
&gt; character
&gt; &gt; simplifies the parsing and interpretation of
XRIs
&gt; (it
&gt; &gt; reduces the number of separator chars from 3
to
&gt; 2).
&gt; &gt; 
&gt; &gt; 2) As Gabe's summary points out, it
eliminates any
&gt; &gt; special rules about "implied" reassignable
&gt; decorators
&gt; &gt; (currently leading dots) in segments.
Instead, the
&gt; &gt; rules would now be crystal clear: slashes
and
&gt; stars
&gt; &gt; are separators; the presence of a colon
after
&gt; either
&gt; &gt; one (or a GCS char) indicates the segment is
a
&gt; &gt; persistent identifier; the absence of a
colon
&gt; means
&gt; &gt; the segment is a reassignable identifier.
&gt; &gt; 
&gt; &gt; 3) The elimination of such special rules
&gt; simplifies
&gt; &gt; XRI normalization and comparison.
&gt; &gt; 
&gt; &gt; 4) This overall simplification of XRI
construction
&gt; &gt; also simplifies the development of XRI
&gt; applications
&gt; &gt; such as XDI.
&gt; &gt; 
&gt; &gt; =Drummond
&gt; &gt; 
&gt; &gt; 
&gt; &gt; --- "Wachob, Gabe" &lt;gwachob@visa.com&gt;
wrote:
&gt; &gt; &amp;gt; Loren-
&gt; &gt; &amp;gt; 	I think the discussion is whether
the
&gt; proposed
&gt; &gt; &amp;gt; change should be adopted. If we
take no
&gt; action,
&gt; &gt; the
&gt; &gt; &amp;gt; change will not be adopted.
&gt; &gt; &amp;gt; 	As to whether this is an
aesthetic-only
&gt; change,
&gt; &gt; &amp;gt; I'll let the initial proponents of
this
&gt; proposal
&gt; &gt; &amp;gt; speak up. I think it's largely
aesthetic, but
&gt; can
&gt; &gt; see
&gt; &gt; &amp;gt; some technical value in the
simplification of
&gt; &gt; &amp;gt; comparison (no need to account for
"implied"
&gt; &gt; leading
&gt; &gt; &amp;gt; *'s in segments).
&gt; &gt; &amp;gt;
&gt; &gt; &amp;gt; 	-Gabe
&gt; &gt; &amp;gt;
&gt; &gt; &amp;gt;
&gt; &gt; &amp;gt;
&gt; &gt;
__________________________________________________
&gt; &gt; &amp;gt; gwachob@visa.com
&gt; &gt; &amp;gt; Chief Systems Architect
&gt; &gt; &amp;gt; Technology Strategies and Standards
&gt; &gt; &amp;gt; Visa International
&gt; &gt; &amp;gt; Phone: +1.650.432.3696   Fax:
+1.650.554.6817
&gt; &gt; &amp;gt;
&gt; &gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; -----Original Message-----
&gt; &gt; &amp;gt; &amp;gt; From: Loren West
&gt; &gt; [mailto:loren.west@epok.net]
&gt; &gt; &amp;gt; &amp;gt; Sent: Wednesday, July 07,
2004 11:05 AM
&gt; &gt; &amp;gt; &amp;gt; To: Wachob, Gabe;
&gt; xri@lists.oasis-open.org
&gt; &gt; &amp;gt; &amp;gt; Subject: RE: [xri] Issue
1: Clarifying *
&gt; &gt; Semantics
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; Is there any technical
basis for this
&gt; &gt; change?
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; Issue #1 is easy for me
because there's
&gt; a
&gt; &gt; &amp;gt; technical reason that we
&gt; &gt; &amp;gt; &amp;gt; chose the wrong character.
 Issue #2
&gt; seems
&gt; &gt; to be
&gt; &gt; &amp;gt; purely aesthetics
&gt; &gt; &amp;gt; &amp;gt; as it works equally both
ways.
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; So - are we discussing
which one we
&gt; think is
&gt; &gt; &amp;gt; aesthetically more
&gt; &gt; &amp;gt; &amp;gt; pleasing?
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; I have an opinion as to
which one I
&gt; prefer,
&gt; &gt; but
&gt; &gt; &amp;gt; that opinion pales
&gt; &gt; &amp;gt; &amp;gt; in comparison to my
opinion on changing
&gt; the
&gt; &gt; &amp;gt; specification for
&gt; &gt; &amp;gt; &amp;gt; aesthetic purposes only.
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; =Loren
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; -----Original Message-----
&gt; &gt; &amp;gt; &amp;gt; From: Wachob, Gabe
&gt; [mailto:gwachob@visa.com]
&gt; &gt; 
&gt; &gt; &amp;gt; &amp;gt; Sent: Wednesday, July 07,
2004 10:44 AM
&gt; &gt; &amp;gt; &amp;gt; To:
xri@lists.oasis-open.org
&gt; &gt; &amp;gt; &amp;gt; Subject: [xri] Issue 1:
Clarifying *
&gt; &gt; Semantics
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; I'm attempting to
summarize the issue
&gt; here -
&gt; &gt; if
&gt; &gt; &amp;gt; you feel I'm
&gt; &gt; &amp;gt; &amp;gt; misstating it,
&gt; &gt; &amp;gt; &amp;gt; please chime in.
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; Issue 1: There is some
desire to clarify
&gt; the
&gt; &gt; &amp;gt; semantics of "*"... If we
&gt; &gt; &amp;gt; &amp;gt; convert to using "*"
instead of ".",
&gt; there
&gt; &gt; was a
&gt; &gt; &amp;gt; feeling that
&gt; &gt; &amp;gt; &amp;gt; we should
&gt; &gt; &amp;gt; &amp;gt; change the semantics of
'*', to make it
&gt; a
&gt; &gt; pure
&gt; &gt; &amp;gt; separator, instead of a
&gt; &gt; &amp;gt; &amp;gt; separator and a decorator
(indicating
&gt; &gt; &amp;gt; reassignability).
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; In XRI 1.0, both : and *
are separators
&gt; and
&gt; &gt; &amp;gt; decorators. That
&gt; &gt; &amp;gt; &amp;gt; is, they both
&gt; &gt; &amp;gt; &amp;gt; indicate that the
following token is a
&gt; &gt; subsegment,
&gt; &gt; &amp;gt; and that
&gt; &gt; &amp;gt; &amp;gt; reassignability
&gt; &gt; &amp;gt; &amp;gt; of a following subsegment.
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; The proposal here is to
convert * to a
&gt; pure
&gt; &gt; &amp;gt; separator and : to a pure
&gt; &gt; &amp;gt; &amp;gt; decorator. That is, all
subsegments are
&gt; &gt; delimited
&gt; &gt; &amp;gt; by * and persistent
&gt; &gt; &amp;gt; &amp;gt; subsegments begin with a
:...
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; XRI 1.0:
xri+example/degenerate
&gt; &gt; &amp;gt; &amp;gt; XRI 1.1:
xri+example/degenerate
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; XRI 1.0: 
xri:+example.simple/:45:45:34
&gt; &gt; &amp;gt; &amp;gt; XRI 1.1:
&gt; xri:+example*simple/*:45*:45*:34
&gt; &gt; &amp;gt; &amp;gt;
&gt; &gt; &amp;gt; &amp;gt; XRI 1.0:
&gt; &gt; xri:+example.simple/another.segment:43:55
&gt; 
=== message truncated ===



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]