RE: [xri] Why I don't like compact syntax. (It is misleading.)

["Drummond Reed" <drummond.reed@cordance.net>]

Steve,

I assure you the motivations for compact syntax go much, much deeper than
MXRIs. The motivation is deeply rooted in dealing with simplification of the
single most powerful feature of XRI architecture, cross reference, which
unfortunately in the current XRI Syntax 2.0 architecture are easy for
machines to deal with and very hard for humans to deal with.

Compact syntax is a solution. While I agree that there are a handful of
cases in which it might be confusing to a non-technical reader new to XRIs,
IMHO that pales to the number of places where our current cross-reference
syntax is absolutely unintelligible to ordinary mortals.

Furthermore, if XRI is to truly become a widespread "language for
identifiers", then human readability and understandability of XRIs that
include cross-references is of high importance. That's why this issue is so
important in my view.

You are correct that compact syntax essentially turns all GCS characters
into delimiters. That's what I believe will be the outcome of the revisions
to the ABNF once we start into it. However, having considered this for
awhile, I believe the result will be cleaner and cleared ABNF with fewer
exceptions.

I look forward to discussing more on the call tomorrow (however I suspect
that like most deep issues it may take an in-person whiteboard session to
really understand it deeply, but we'll get as far as we can).

=Drummond 

-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Wednesday, February 14, 2007 6:24 PM
To: xri@lists.oasis-open.org
Cc: andy.dale@ootao.com
Subject: [xri] Why I don't like compact syntax. (It is misleading.)


Here's my beef with the compact syntax proposal.

XRI has two types of operators - segment delimiters and subsegment
delimiters. The segment delimiters are always the '/' character and (until
lately) the subsegment delimiters were '*' or '!' depending upon the
persistence of the subsegment. [Granted the '*' is absent following a
leading GCS character.]

The compact syntax proposal is to shorthand away the "*" [and cross-ref
parens] whenever the non-persistent subsegment begins with a GCS character.

My contention is that the compact syntax misleads a reader into thinking
that the GCS character is really some kind of an operator.

Rather than seeing the "email address example" as a benefit, I view this is
as the opposite: a particularly egregious example of a GCS characters
appearing to be an operator and misleading the reader.

In the email address bill.gates@microsoft.com the reader interprets the "@"
as an operator meaning: the organization on the right side of the operator
(microsoft.com) is authoritative for the user name on the left side of the
operator (bill.gates). If it authenticates (if I can send an email to it)
then I know I'm dealing with the Bill Gates at Microsoft.

In the proposed compact syntax, (if I happen to own =bill.gates) I can
easily create a valid (authenticating) i-name =bill.gates@microsoft.com.
Whereas this iname authenticates, it has nothing to do with the Bill Gates
at Microsoft.


I would submit that a reasonable reader would misinterpret the "@" in this
case to be an operator that has the same meaning that it does in
bill.gates@microsoft.com above. 

If the issue comes down to "misleading" vs. "not-as-compact-as-possible", I
certainly vote for the latter.

If we are really that interested in this new requirement of supporting email
addresses as i-names, then I think that -- in addition to the compact syntax
proposal -- we should also consider flipping the XRI delegation order to
"right to left". [Surely, I jest.] At least then we would not be guilty of
misleading, because then microsoft.com would really *be* authoritative for
=bill.gates.

If the motivation for introducing the XRI compact syntax is this new
requirement of supporting email addresses as i-names, then I think the
argument above is enough to counter that. If the motivation is so that
typing XRIs in text editors is easier and shorter, then that's what "text
editor syntax plugins" are all about. These will be able to project a text
editor view of XRIs that is appealing and natural for the person doing the
typing. Hell, he or she can probably even tell the plugin to hide the stars
if they want.


~ Steve
@ootao*steve=smart+rich+handsome   (and we all know *that's* misleading.)