Encoding XDI attributes into XRIs

["Loren West" <loren.west@epok.net>]

XDI TC,

Apologies for the lengthy thread.  The summary is that
I'm proposing we don't map XRI "." and "/" to <link> and
<resource>.  If you want to be bored with the details, 
read on...

I'd like to raise (and hopefully close on) an issue that
has been bugging me for a long time.

It has been suggested that we encode an attribute of a
relationship within the XRI - that a slash character would
mean containment, and a dot would mean link (or not owned
by the parent resource).

The reason I'm bringing this up now is an observation that
slashes in an XRI are at a different level than dots. 
Slashes are segment separators, while dots (and colons) are
sub-segment separators.  Take this example:

=Loren/Business.Card/AddressLine1

There are 3 segments of the above XRI - not 4.  The second
segment is "Business.Card".  You don't need to surround
Business.Card with parens to know it's an entire name
within the segment.  There are no rules for breaking down
sub-segments within segments EXCEPT for the first segment
(which provides the communications endpoint).

We could impose rules, and we may, but there are no current
rules in XRI in regards to breaking down sub-segments past
segment 1.

Which brings me back to "." meaning link, and "/" meaning
resource.  A discussion on another list makes it clear that
real people like to use "." as a word separator within a
namespace.  They're used to a name like autoexec.bat or
business.card, and don't like it if you don't let them 
use "." as a word separator within a namespace.

Luckily, we've only defined the use of sub-segments in the
first segment of an XRI, and we're resolving the issue
within that segment.  I wouldn't want to add semantics
to other segments that prevent people from using "." in
names for resources.

That's the syntactical reason I'm opposed to it.  We could
possibly get around that, but there's a bigger reason I'm
opposed to it.

Resources have many attributes.  Relationships between
resources have many attributes as well (see the discussion
of LinkContract on this list).  Attributes change.  It's
a fact of life.  Relationships change their character, and
if you encode one attribute of that character into the NAME
of the relationship (the XRI), then changing that attribute
invalidates existing references to that relationship.

And that's a bad thing.

The basic rule of naming is that the more attributes you
put into a name, the more semantics you put into a name,
the more likely it is that the change to those semantics
will render the name unusable.

For these reasons I propose we discontinue the discussions
of encoding any XDI attribute into the XRI, and specifically
the proposed "relationship type" attribute.

=Loren