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: [xri] POLL: Syntax 2.0 or 2.1


In a message earlier today regarding the example XRI of
"@ootao+west*steve" Drummond said he '...was implying that @ootao is in
fact authoritative for it's own definition of "+west".' If that's true,
then I see no reason to support the "+" namespace at all; @ootao could
just as well use "@ootao*west*steve". 
 
Drummond provided an XDI RDF address (#1) of an attribute of one of his
personal personas, expressed using the direct concatenation in the XRI
Syntax 2.1proposal:

#1:	=drummond+work/+person+name+first

I suggest the following (#3) as a way to express the same (or at least
similar) relationships using 2.0 syntax:

#3:   =drummond*work/+person*name*first

In neither #1 nor #3 is it clear to me where to send the resolution
query for "+person", although if someone understands what to do with
+person in #1, I suppose they would also understand what to do with
+person in #3.

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Tuesday, May 01, 2007 9:52 PM
To: 'Steven Churchill'; 'Tan, William'; 'Gabe Wachob'
Cc: xri@lists.oasis-open.org
Subject: RE: [xri] POLL: Syntax 2.0 or 2.1

Steve (and everyone on this thread),

I think we are talking past each other RE what I'm saying about the role
of XRIs and XDI RDF. XDI RDF doesn't do anything to change the RDF graph
model, that's why it's called XDI RDF. Everything is triples. It does,
however, use a different serialization model than RDF, and the primary
reason it does that is *addressing*. As Bill Barnhill so well summarized
it at our f2f meeting, the XDI RDF model has three breakthrough features
over conventional
RDF:

1) No blank nodes.
2) Automatic reification.
3) All statements are identifiers and all identifiers are statements.

All three of these features are a direct result of the core design
principle of XDI (in both the ATI and RDF models): 100% addressability
of all nodes in the graph. In fact, in the XDI RDF model, not just all
nodes addressable, but all XDI statements (arcs) are addressable -- even
the refs (in the XDI ATI model, we needed a workaround to make refs
addressable).

In short, THE killer feature of XDI RDF is addressing, which depends
completely on XRIs. In particular, it depends on the ability of XRI to
compose identifiers out of other identifiers -- both global and local
identifiers.

When it comes to addressing, the value of direct concatenation to the
XDI RDF model is the simplicity of the XRIs used to address nodes in the
XDI RDF graph. In response to Gabe's earlier note about "having these
requirements in front of us", I have repeatedly tried to make sure
everyone on the XRI TC was aware of how significant this factor is by
pointing them to the very detailed XDI RDF proposal, currently in its
fourth version:

http://www.oasis-open.org/committees/download.php/23161/xdi-rdf-model-v4
.pdf

This is the XDI addressing model that I have been referring to
throughout the development of XRI Syntax 2.1. If you have not read this
document, I strongly urge you to take the time to read through it and
look over the example XDI documents (in four serialization formats, no
less) and the XDI addresses they contain. I think they provide very rich
examples of the dramatic difference that direct concatenation makes in
the simplicity of XDI RDF addresses. 

By simplicity, I mean two things:

1) Human-readability and understandability, which has a huge amount to
do with adoption by developers, directory administrators, and other IT
personnel who (we hope) will be dealing with XDI addresses on a day to
day basis (just like they deal with IP addresses, domain names, and URIs
on a daily basis), and for whom human-readability and understandability
is a serious factor in adoption (witness HTML).

2) Comparability, i.e., the ability to take two XRIs and compare them
without complex normalization rules.

Since this topic is so important (why else would I be typing this late
into the night...), let me provide a detailed example from the document
I cited.
The following is an XDI RDF address of an attribute of one of my
personal persons, expressed using the direct concatenation in the XRI
Syntax 2.1
proposal:

#1:	=drummond+work/+person+name+first

Now, here's the closest address that one could TRY to compose that
expressed the same relationships using 2.0 syntax:

#2:	=drummond*(+work)/(+person*(+name*(+first)))

I emphasize "TRY to compose" because the grammar expressed in the second
address is NOT EQUIVALENT to the first one. That's what I was trying to
explain in the f2f meeting: global-xrefs, the ABNF rule that enables
direct concatenation (see
http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1) are not a "compact"
way of expressing local-xrefs, as I (and all of us) first thought. As
Les puts it, they are a different grammatical construct than a
local-xref, because they are a reference to a resource in a global
context vs. a local context. (To use an English language analogy, this
is like the difference between saying "Drummond Reed" and "Drummond's
Reed".
Grammatically they are very different.)

That point alone is very important, but back to my original point: look
at these two addresses. See how intuitive #1 is. Here at the Higgins
f2f, folks who had never worked with XRI have been able to just go to
the whiteboard and write one without thinking.

Now, imagine them trying to do that for #2.

Yes, I know you can make a case (as Wil has) that "most people will not
need to understand XRI syntax". And you can also make a case (as Steve
has) that "global xrefs add complexity to XRI parsing and resolution".
But I hope you can understand why I am pushing back so hard on those
arguments. It's not that I don't understand them -- I do. 

It's that I believe they don't outweigh the tremendous intuitive and
expressive power of direct concatenation. Besides being brain-dead easy
to read, it gives any person who knows how to type the ability to tag an
XRI just by adding "+tag". To say we shouldn't do this because we didn't
understand how this would possible in earlier versions of XRI syntax
(which is the absolute truth -- do you think that if we had seen this in
XRI 1.0 or 2.0 we would not have done it??) would be the TC equivalent
of saying, "Yes, cars may be faster than horses but they are more
complex and require gasoline and spew exhaust, so let's just stick with
horses."

That's as much as I can put in an email tonight (though I'm doubtful
email will be very productive towards resolving this issue). I'll
schedule it for Thursday's telecon.

=Drummond 



-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Tuesday, May 01, 2007 6:25 PM
To: 'Drummond Reed'; 'Tan, William'; 'Gabe Wachob'
Cc: xri@lists.oasis-open.org
Subject: RE: [xri] POLL: Syntax 2.0 or 2.1


Drummond,

It strikes me as funny that you continue to use XDI RDF as the
motivation
for adding complexity to the abstract models of XRI syntax and authority
resolution. It is ironic, because I think you have failed to take away
one
of the most important lessons that the RDF folks have to offer: that of
the
importance of a foundation based upon a solid and simple abstract model.

I urge you to take a look at the normative document "RDF Concepts and
Abstract Syntax" <http://www.w3.org/TR/rdf-concepts/>. If you do, you
may
note the following:

1. 	The RDF abstract graph model IS formally defined. (Kudos to
them!)
See section 3.1 "Graph Data Model". The XRI/XRI TCs have consistently
"avoided" formally defining their abstract syntax and graph models.

2.	The incredible simplicity of the RDF graph model. This is by
design,
not by accident.

3. 	Note the language of section 2.2.4: "RDF has a recommended XML
serialization form [RDF-SYNTAX], which can be used to encode the data
model
for exchange of information among applications." 
To the RDF folks, the serialization format is not the "heart" of the
specification -- it is a recommendation. If only RDF XDI could take away
that lesson and focus on its graph model instead of its serialization
format! 

So you keep using (XDI) RDF as a motivation for adding complexity to the
XRI
models. I personally consider RDF as a perfect example of why we should
NOT
do so.

~ Steve



-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Tuesday, May 01, 2007 3:44 PM
To: 'Tan, William'; 'Gabe Wachob'
Cc: xri@lists.oasis-open.org
Subject: RE: [xri] POLL: Syntax 2.0 or 2.1

Again, I want to make sure it's clear why this is such a big issue: the
XDI
RDF model uses the "grammer" of global-xrefs. This "grammer" cannot be
duplicated (at least in any easy way I can figure out) by "going back"
to
2.0 syntax.

So this issue is deep, deep, deep.

=Drummond 

-----Original Message-----
From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Tuesday, May 01, 2007 3:33 PM
To: Gabe Wachob
Cc: xri@lists.oasis-open.org
Subject: Re: [xri] POLL: Syntax 2.0 or 2.1

Yes. Xrefs can only appear within parentheses.

Gabe Wachob wrote:
> Can you spell out the implications of this choice so we know exactly 
> what
it
> is we are voting for/against? 
>
> That is, we are saying that XREFs basically stay as is and that the 
> @foo+bar+baz syntax goes away?
>
> 	-Gabe
>
>   
>> -----Original Message-----
>> From: Tan, William [mailto:William.Tan@neustar.biz]
>> Sent: Tuesday, May 01, 2007 3:25 PM
>> To: xri@lists.oasis-open.org
>> Subject: [xri] POLL: Syntax 2.0 or 2.1
>>
>> We did an informal poll at the f2f two weeks ago on whether we should

>> stick with XRI Syntax 2.0. I suggest we vote again on the list.
>>
>> +1 - to support concatenated syntax
>> 0 - don't care
>> -1 - no concatenated syntax
>>
>> I'm reverting my vote to -1 because the solution is too confusing
IMHO.
>>
>> =wil
>>     
>
>
>   



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