RE: [xri] One vs. two alt hierarchy characters

["Dave McAlpin" <Dave.McAlpin@epok.net>]

I'm much better at technical details than I am at worldviews, so I'll
comment on this thread. You make three points below to support *: over
simply :.

1) Sometimes dot is optional.

I assume this would be true with star as well, wouldn't it? If
xri:@example is equivalent to xri:@.example, wouldn't it be equivalent
to xri:@*example under the new syntax?

2) Sometimes colon means delegation, sometimes it just means
persistence. Example: in "@:foo:bar/:baz", the first colon does NOT mean
delegation, it only means the subsegment "foo" is persistent, but the
second colon means delegation to the identifier authority identified as
"bar".

I disagree. If there's no dot or colon after @, there's an implicit dot.
In standard resolution, there IS delegation beween @ and the next
subsegment, whether that subsegment is persistent or reassignable (and
whether the dot is explicit or implicit).

3) Colon may be useful for other purposes. You propose two cases, one
where colon is just a normal character and one in which it is a new kind
of delimiter.

The first (colon is a normal character) is clearly disallowed by
2396bis. Colon is part of the pchar production, so it's legal in a path
component. However, it's also part of the reserved production, via
gen-delims, and section 2.2 of 2396bis says "each syntax rule lists the
characters allowed within that component (i.e., not delimiting it) and
any of those characters that are also in the reserved set are 'reserved'
for use as subcomponent delimiters within the component."

The second case (e.g. =Bob.Smith:England) is allowed as long as the
semantics of colon are baked into either the syntax or resolution spec.
This is no different that defining semantics for star, for example.
2396bis says "Only the most common subcomponents are defined by this
specification; other subcomponents may be defined by a URI scheme's
specification, or by the implementation-specific syntax of a URI's
dereferencing algorithm, provided that such subcomponents are delimited
by characters in the reserved set allowed within that component."

With that said, I think it's pretty inelegant to say that colon means
one thing if it follows @, =, +, / or * and something completely
different if it follows any other character.

Dave

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Thursday, June 10, 2004 4:36 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] One vs. two alt hierarchy characters
> 
> I'm starting a new thread now that we're on to the "second half" of
the
> alternative hierarchy character issue. (Note that Dave calls this the
> "secondary hierarchy character" issue, with slash being the "primary
> hierarchy character", but since I believe such distinctions may depend
on
> your POV, I'm just going to call it the alternative hierarchy
character,
> or
> alt-hier char.)
> 
> Anyway, the second half of the alt-hier char issue is whether there
should
> be just one alt-hier char, or two. The XRI 1.0 spec has two - dot and
> colon.
> Loren, Dave, Gabe, and Mike have all already expressed a preference to
> keep
> two, which if star is adopted in place of dot, would mean star and
colon.
> 
> Let me then state the case for having only one. In this design, star
would
> be the alt-hier char, and in XRI syntax colon would only have a
special
> meaning when used as the first character of a subsegment, in which
case it
> would designate this subsegment as persistent. (The BNF for this is at
> http://xrixdi.idcommons.net/moin.cgi/ProposedXriSyntaxRevision#head-
> 1e821383
> 5f5624d207ee790744620ea15cf0022f).
> 
> The rationale for this approach falls into three buckets:
> 
> RATIONALE #1
> 
> The first reason is that in XRI 1.0, both dot and colon were
overloaded
> with
> two meanings: first, they were alt-hier chars, and second, they had
> persistence semantics (dot = reassignable sub-segment and colon =
> persistent
> sub-segment).
> 
> This resulted in two funky situations:
> 
> 1) Sometimes dot is optional, i.e., since the default subsegment type
is
> reassignable, you only needed dots for subsequent reassignable
> subsegments.
> Example: in "@foo/bar.baz", "foo" and "bar" are reassignable, but they
> didn't need dots because reassignable is the default. So
"@foo/bar.baz" is
> actually equivalent to "@.foo/bar.baz" and "@.foo/.bar.baz". This
required
> covering this in the equivalence section of the spec, and thus
potentially
> in every XRI equivalence engine every built.
> 
> 2) In XRI 1.0 resolution, sometimes colon means delegation, sometimes
it
> just means persistence. Example: in "@:foo:bar/:baz", the first colon
does
> NOT mean delegation, it only means the subsegment "foo" is persistent,
but
> the second colon means delegation to the identifier authority
identified
> as
> "bar".
> 
> By designating one XRI syntax char as the alt-hier char (star) and one
as
> the leading char for persistent subsegments (colon), we eliminate both
> funky
> situations. Star would always mean alternate hierarchy, and colon
would
> always mean it denoted a persistent subsegment, and these rules would
be
> uniform everywhere.
> 
> RATIONALE #2
> 
> The second rationale for only having one alt-hier char is that
simplied
> rules mean simplified parsers, because they have only two hierarchy
chars
> to
> parse - slash and star - and only one way of denoting persistent
segments
> (they all start with colon), with no overloading. Gabe has said he
> believes
> this is a weak reason, but Fen, who has also written an XRI resolver,
> thinks
> it is a relatively strong one. I'll let Fen speak further to this.
> 
> RATIONALE #3
> 
> The third reason for not keeping colon as an alt-hier char, and
possibly
> the
> strongest one in my view because it speaks to actual use cases vs.
> aesthetic
> or technical preferences, is the same as one reason for moving away
from
> dot
> as an alt-hier char, namely that it frees up colon to be used as a
normal
> character (after the first character) within XRI subsegments.
> 
> I have come across an increasing number of cases where colons are
already
> used in some fashion in existing identifiers - most specifically IPv6
> addresses (which are reassignable). Just as not using dot as an
alt-hier
> char allows us to permit strings that already use that char (e.g. DNS
> names)
> as XRI subsegments, not using colons as an alt-hier char would enable
us
> to
> permit strings that already include colons as XRI subsegments.
> 
> It would also allow us to design new strings that use colons as
logical
> delimiters for other human readability and usability purposes. A
specific
> use case is a design challenge facing those of us working on XRI
registry
> services. By allowing dots as logical separators for personal or
> organizational e-names (reassignable XRIs registered under the = or @
GCS
> chars), we open up these namespaces to many more expressive and
> mnemonically
> distinctive compound names, e.g., "=Bob.Smith", "=Bob.H.Smith", and
> "=Bob.Henry.Smith". However for certain common personal names, these
three
> combinations may all be registered. For example, all it takes is for 3
> gentlemen named "Bob Henry Smith" to register the 3 variants above and
> suddenly the 4th "Bob Henry Smith" is stuck.
> 
> In this case it would be helpful to have a convention for how
registrants
> can turn their desired e-name (be it either simple or compound) into
> something globally unique e-name by adding a "postfix" - another name
> segment offset by a logical delimiter DIFFERENT than dot because the
> namespace-specific meaning of this logical delimiter would be, "the
> following segment is added only for global uniqueness".
> 
> If star becomes the alt-hier char, our only other char choices that
are
> not
> already declared in XRI 1.0 are single quote, comma, semicolon,
ampersand,
> dash and colon. Single quote, comma, and semicolon are all undesirable
> because they are too hard to distinguish (either at all, or from other
> similar chars.) Ampersand is too hard to write and say. Dash is
> undesirable
> because it is already a natural language character used in some
Western
> names, e.g., "Mary Smith-Johnson" or "Bob Smith-Johnson". That leaves
> colon.
> Given the use of dots as the other logical separator in compound
names,
> colons are in fact a natural choice. For example, using the
"=Bob.Smith"
> case, you could have:
> 
> =Bob.Smith:England
> =Bob.Smith:Hawaii
> =Bob.Smith:Red
> =Bob.Smith:Jupiter
> =Bob.Smith:Rocket
> 
> All of these would tell the parties reading the e-name that the
> registrant's
> preferred name is "Bob Smith", and that the segment after the colon is
> added
> only to achieve global uniqueness.
> 
> At Cordance we have run some small tests of this syntax with end-users
and
> received very favorable results. They understand the distinction
clearly
> and
> feel the "meaning" of colon is appropriate here.
> 
> *****
> 
> One last point: I've seen a number of mentions that with e-numbers,
the
> separation of star (for alt-hierarchy) and colon (for persistence)
results
> in longer identifiers that don't "look" as nice because they use
double
> chars ("*:" instead of just ":") to delimit persistent segments.
> 
> However this applies only to the global authority segment where the
XRI
> spec
> defines resolution rules. As others have pointed out, after the first
> slash,
> the meaning of colon can be defined by the local authority, and any
> authority is free to define colon by itself to mean BOTH persistence
(as
> required by the XRI spec) AND delegation to another authority in their
own
> namespace (i.e., give it the same meaning : has in XRI 1.0).
> 
> That means the only real effect of separating the alt-hier char and
the
> persistent-segment char is in the global XRI authority segment. Since
I
> believe more than two levels of delegation will be rare in this space
> (just
> as more than two levels of delegation in DNS names is relatively rare,
> i.e.,
> www.example.com), and since e-numbers are not intended for human
> readability
> anyway, I believe this tradeoff is justified and actually makes
delegation
> within global e-numbers easier to read and understand by developers.
> 
> =Drummond
> 
> 
> 
> 
> 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.