[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
> -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Thursday, September 22, 2005 4:38 PM > To: Schleiff, Marty; Drummond Reed; xri@lists.oasis-open.org > Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for Identifier > Metadata > > > > Regarding SUMMARY NOTE: If I think of it from the perspective > > of an XRI > > resolver, I think it would be better to express even a mailto > > within XRI > > with a $t. That way, software will be able to recognize it as > > an XRI and > > invoke their XRI processor which will know how to deal with > > it. > > Well, in any case, even if it were a mailto: URI, it would be a > *cross-reference* to a mailto: URI, and an XRI processor could > definitely have rules that are specific to each URI type appearing in a > cross reference. That is, just because there is a well-defined operation > for using mailto: URIs (ie SMTP), this doesn't mean that an XRI > processor can't be instructed to do something else with a mailto: URI > *when it appears in a cross-reference*. > > You can *always* do xri://(mailto:gwachob@wachob.com) or > xri://@sfgiants*fans*(mailto:gwachob@wachob.com) > > In either case, the mailto URI can be treated as an XRI subsegment or a > mailto: URI - there's no real need to make it > $t*mailto*gwachob@wachob.com (which would be illegal I think, given the > @ in the middle of a subsegment that isn't a cross-reference). [Chasen, Les] Just one comment, It probably should not be the resovler (XRI Resolution client) that is determining what to do with a URI. It just knows how to lookup and find the XRID. It is some other service that determines how to process a URI. NOTE: I am not making any judgment on whether this should be a tag or not ... just pointing out where I think functional applications/services belong. > > > I may be > > dreaming, but it seems that way down the road we could define an XRI > > type definition language that we use to describe the caracteristics of > > each identifier type. Then the XRI resolver wouldn't even have to > > understand what is meant by ($t*mailto); instead it could just lookup > > the characteristics of mailto and process it accordingly. Such XRI > > resolver applications would not need to be enhanced whenever new > > identifier types are introduced; they'd only require modification when > > the type description language changes. Am I dreaming too large? > > You may be dreaming, but I don't see why such a mechanism couldn't also > apply to xrefs containing particular URI types (ie a rule each for > mailto xrefs, http xrefs, etc) [Chasen, Les] Same comment as above. The resolver should not be doing anything here. It is the specific service application that knows what to do with any specific piece of meta data. For example, it is an xri aware email engine that is taking the mailto tag and determining what to do. The email engine makes a resolution request via a resolver to look up the needed data. > > -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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]