RE: [xri] Update to Metadata Issue #1: Add $t Tag for Identifier Metadata

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

Agreed that we need to take it to the phone. If the first two items go
reasonably quickly, we should be able to have to discuss this.

BTW, I like your examples below, and your idea of "$t*uri" being able to
describe any existing URI scheme is brilliant.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Thursday, September 22, 2005 5:36 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for Identifier
Metadata

Drummond-

This back and forth isn't clearing much up for me. Having a concrete
example or two about whats missing in the current syntax would help. 

As for the assertion that $t isn't just for
as-yet-undefined-URI-schemes, if you are saying that $t namespaces are
more valuable because they are resolvable, and therefore reusing URI
schemes is suboptimal, then why can't you specify the following
identifiers, each of which resolves to something:

$t*oid
$t*ip
$t*uri*mailto
$t*uri*http

This seems to address all the use cases about having a dictionary of
types. And for reusing URIs, you don't have to reinvent syntax - I still
don't see why (mailto:gwachob@wachob.com) is inferior to
($t*mailto*gwachob%40wachob.com).

> I only bring it up because I'm slowly becoming convinced that 
> XRI does not
> just provide backwards compatability with existing 
> identifiers expressed in
> URI schemes, but a richer way to describe/use any type of 
> identifier at the
> XRI level. This includes new types of identifiers that may 
> have special
> privacy, security, or crypto characteristics. That's why a $t 
> spec is making
> more and more sense to me.

Again, though, if you want to add things to a URI cross reference, you
can do (as a wild stab in the dark since I don't really know what
specifically you are thinking about): 

(mailto:gwachob@wachob.com)*($crypto*2312321321321)
 
> Another way to put the "big picture" use case for $t is this. If: a)
> company's like Boeing and consortia like NAC want to be able 
> to adopt XRI as
> a standard "identifier representation language" that helps 
> them solve the
> problem of identifier interoperability within and between 
> enterprises, and
> b) if one of the requirements of such a language is that they 
> be able to
> express a standard dictionary of identifier types, then they 
> need to be able
> to express all identifiers they need to deal with consistently in that
> dictionary format.

I think the $t*uri*<uri scheme> satisfies this requirement, at least as
I understand it. But I honestly don't really understand what
"consistently" means, and I don't understand what "interoperability"
means in this context. 

> So from the standpoint of that use case, it might not matter 
> if there is an
> existing URI scheme for an identifier type. That's not the 
> "language" they
> need to standardize on. They need a common way to express 
> (and combine, and
> compare) all these identifier types, and for that they need 
> to express them
> all in a common way.

Yes, its called XRI!

More specifically, I really am not seeing where the current
specification (without the $t namespace) is deficient in this regard. I
am waiting to see one use case to clear this up for me... But I haven't
seen it yet. 

> The analogy that DaveM has used several times is that if this 
> were XML and
> it was a data interoperability problem, what would be needed 
> is agreement
> not just to use XML, but a common set of schemas. Instead 
> what we have here
> is an identifier interoperabilty problem, the common 
> "language" is XRI, and
> the common "schema" (dictionary) needed for interoperability 
> of a number of
> existing (and future) identifier types is the $t spec.
> 
> I hope that perspective helps.

I'm not seeing the analogy here. We'll have to discuss this on the
phone, I guess. 

  -Gabe

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php