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: [Openxri-users] Thoughts about XRI aliases


Drummond,


What I am trying to say here is that the XRI authority graph model—at least the one that validates under CID verification—really needs to be presented in the XRI Resolution Specification.

 

This includes a drawing of the graph and descriptions are what are meant by Nodes, Edges, and Refs. It includes descriptions of what is meant by terms such as “local synonyms” and “polyarchical synonyms”.

 

I know that Gabe and others on this TC think that such a notion is absurd. I think just the opposite: Refusing to formalize our abstract models mirrors the classic process of the hacker programmer—just write a bunch of code without the benefit of clearly-defined abstractions. The XRI and XDI TCs write a bunch of specs without the benefit of clearly-defined abstractions.

 

Why do you think it is that RDF clearly defines its abstract graph model—even though it is far, far simpler than the XRI authority graph model?  Yes, they define the meaning of the Nodes and the meaning of the Edges. It is because these folks understand the value of formalizing the model as the foundation of the specification.

 

We clearly do not understand ths, and because of this, we will always have confusion with respect to understanding XRI resolution and implementing clients and servers that are conformant with the specifications. We don’t need to go far for an example of such confusion. Just look at this thread (albeit cut off here.)

 

~ Steve

 

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]

 

Steve:

 

You said at the end you a message this morning:

 

“PS: Drummond, the confusion of this thread arises largely because we HAVEN’T formalized the authority graph model in the XRI resolution spec. Again, we are forcing the abstract model to be reversed engineered from the specification. Very bad. To answer questions such as Markus’s outside of the context of the formal XRI graph representation is mostly an exercise in confused terminology and wasted time (such as this thread.) But alas, I’ve complained about this on several occasions to no avail.”

 

I just want to make sure you know I agree with you 100%. When you say, “I’ve complained about this on several occasions to no avail”, I’m not sure what you mean, because you long ago convinced me that the XRI Syntax 2.1 spec SHOULD have a formal definition of the abstract syntax and graph model. (In fact I’m counting on you to edit it.)

 

I also agree with you that the standout features of the Draft 14 ABNF are:

 

1) It eliminates any difference between the abstract and concrete syntax, i.e., the abstract syntax and graph model are reflected with complete fidelity in the ABNF.

 

2) This means there are no normalization rules. Every XRI is what-you-see-is-what-you-get.

 

3) It is very simple and very regular, which has huge benefits for XRI-based applications or protocols like XDI.

 

Just wanted to clear that up.

 

=Drummond



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