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: 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.)







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