[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
Gabe, answers marked ### inline below. I tried to work in Marty's questions/observations as well. See especially the end, where I tried to respond to your Summary Note as well as to Marty's comments. =Drummond -----Original Message----- From: Wachob, Gabe [mailto:gwachob@visa.com] Sent: Thursday, September 22, 2005 12:09 PM To: Drummond Reed; xri@lists.oasis-open.org Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for Identifier Metadata Drummond- I have feedback/questions about these requirements (lines starting with >>>): 1) To have a uniform, interoperable representation in XRI of different types of identifiers which do not have URI schemes yet are commonly used in enterprise systems. >>> Great requirement. Stated exactly as I would have. See my note after the >>> feedback. 2) For this uniform representation to facilitate matching in enterprise directory systems and other applications that need XRI equivalence checking (see Syntax Issue #1: Directory Attribute Appendix). >>> Fine. Makes sense. 3) For this uniform representation to explicitly include the identifier type metadata so applications can take advantage of this metadata, for example to do a type-specific forms of local resolution or determine equivalent identifiers of other types. >>> I think that the specific use cases need to be listed, or at least criteria for determining if a use case is in or out of scope for this change proposal. I don't really understand what "take advantage of this metadata" is. ### Was Marty's message sufficient for this? ### 4) For this uniform representation to be able to be independent of any specific authority that may assign identifiers of this type. >>> But aren't we saying that these representations are ultimately rooted in $t, which is defined by the metadata spec, which is *us*? Its really that the identifier doesn't need to resolve (outside a cross reference) to any authority, right? We are talking about identifiers for which there is no central registration (and no uniform resolution mechanism) (at least not one that is done through XRI). Isn't that the real requirement here? ### Yes. I may not have worded this well. What I meant was not that the *type* declaration was independent of any authority (as you say, it would be dependent on us, or the delegated authority for the $t spec), and therefore could be used by all authorities that assign identifiers of this type. ### 5) For this uniform representation to be able to be expressed in the context of any authority that assigns or accepts cross-references to identifiers of this type. >>> Is it really about xrefs? Isn't the real requirement that the identifier be usable in a subsegment - and that using xref is just a choice of how to address the requirement? ### Yes. Again, it was just my choice of words (I'm waaaay too close to XRI syntax, obviously.) ### 6) For this uniform representation to be able to be expressed in any other context which may accept an XRI cross-reference. >>> Same as #5.. Is this a real requirement? ### Agreed -- it could be rolled in #5. ### 7) If identifier type metadata is best managed in a separate namespace, for management of this namespace to be handled independently of the Metadata specification and provide mechanisms for third party registrations. >>> Really, this just saying that the list of types is managed independently of the metadata specification, right? ### Right, although I was trying to capture the suggestion in several threads that the delegated spec could specify other mechanisms for registration of $t identifiers. ### SUMMARY NOTE: In general, I still think that we haven't described the use case for this proposal very well. I think the use case is best though of as being "having a way to use external identifier schemes where those external identifier schemes don't have a URI scheme defined" - because if they *do* have a URI scheme defined, (e.g. mailto), we *shouldn't* be using $t... The line of thinking (tell me if I'm wrong) is "well, we need more identifier schemes that work with XRI, but since other folks haven't gone through the process of formally defining a URI scheme for these other identifiers, we'll come along and present an alternate XRI-specific mechanism for embedding those identifiers in an XRI"... Right? ### While I fully understand this interpretation, there's more too it than that. What the work that Dave and I have been doing with Marty and Boeing and NAC has revealed to me is that URI syntax is not nearly as rich as XRI syntax in being able to provide a description of an identifier. With URI syntax, as best I know, you have only one option: a scheme name (and the accompanying scheme spec). XRI syntax provides a way to "reuse" this by encapsulating a URI that uses this scheme name so that you can use it as a cross-reference in an XRI. With XRI syntax, however, you can create a "native XRI identifier" for an identifier type. This native XRI identifier has some advantages. First, it's extensible in ways that a URI scheme isn't. For example, if we were to define "$t*oid" for OIDs, an organization Foo that only allows OIDs of a certain type could extend this to become "$t*oid*(@foo)". The meaning that the identifier being described was an OID would not be lost, but be constrained the way @foo desired (in their own context.) The second advantage is the one Marty's been raising. To my knowledge, URI scheme names are not resolvable (not by any protocol I know of.) XRI GCS characters, by contrast, can be resolvable. Marty's particularly interested in the potential for a resolvable $t dictionary because it could provide a long-term solution to the problem of identifier interoperability among directory vendors. Rather than having to add support for specific hard-coded identifier types, they could move towards supporting a $t dictionary. (Again, the scope of that work does NOT fall in Metadata 2.0 and may not even be in the scope of a $t spec. That's future stuff.) 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. 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. 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. 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. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]