[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]