[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Proposal for _xrd_r parameter and return format
I have a few comments. 1. I am not in favor of adding this capability to the spec for http proxy resolution servers. I feel that the capabilities already provided for in the spec allow implementers to build edge resolution services that support this type of functionality. I think implementers who need this type of functionality should be encouraged to write to programmatic interfaces not http proxy resolution servers. 2. If you guys want to add this then this has to be optional behavior. We discussed this on the call but I don't see it documented. 3. This proposal is adding CanonicalId to the service block. Is this only used in the service block under these circumstances? If so is that going to add confusion? I think it might because sometimes I will see the canonical id in a service block sometimes I will see it outside the service block depending on what I ask for. - Les I-Name: =les.chasen -----Original Message----- From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Friday, February 24, 2006 4:33 PM To: xri@lists.oasis-open.org Subject: [xri] Proposal for _xrd_r parameter and return format Per my second action item from yesterday's TC call minutes, this is a proposal to add an _xrd_r (Return) input parameter to XRI Resolution 2.0 Working Draft 10. Background: this originated in the decision that the standard output of XRI resolution when service endpoint selection is requested should be not just a prioritized list of URIs, but also a prioritized list of CanonicalIDs, so that XRD authors have the ability to tell consuming applications the identifier(s) they should use for a resource at a specific service endpoint. It's easy to see how such a return value can be returned via a local XRI resolver API, and that's out of scope for the spec. But it raised the question of how such a result could be returned via an XRI proxy resolver which has only an HTTP interface, and which is in scope of the spec. The proposed solution is two parts: PART ONE: _XRD_R PARAMETER Like _xrd_n, the _xrd_r (Return) parameter would be a Boolean flag. The default if it is omitted or its value is null is the implied value of "false", which means the return type is be governed by the _xrd_m (MediaType) attribute. If _xrd_r="true", then the resolver MUST return an XML document consisting of only the selected service endpoint (part two). PART TWO: SERVICE ENDPOINT DESCRIPTOR 2) To keep it as simple as possible, the proposed return format if _xrd_r="true is an XML document that reuses the xri://$xrd*($v*2.0) XML namespace and just contains the selected Service element. Following is a example: <Service xlmns="xri://$xrd*($v*2.0)" > <ProviderID>xri://!!1000!1234.5678</ProviderID> <CanonicalID>xri://=!A1B2.C3D4</CanonicalID> <Type select="true">xri://+contact*($v*1.0)</Type> <Path match="null" /> <URI priority="10">http://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> <URI priority="15">http://alt.example.com/contact/=!A1B2.C3D4?id=xri://@foo</ URI> <URI>https://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> </Service> To support this return format would require that we add CanonicalID as an optional child of the XRD Service element. This means CanonicalID could appear at both the XRD level and the Service level exactly the way ProviderID can currently appear at both levels. This has the additional benefit of allowing CanonicalID to be expressed on a more granular service level rather than just at the XRD level. The rule would be that CanonicalID would be used directly if present in the selected Service, or it would be "inherited" from the XRD level if it was not present for the selected Service. In other words, CanonicalID at the XRD level is the default for every Service unless the Service overrides it by including 1+ CanonicalID elements. In addition, in a Service document the values of the URI element would be "fully constructed", i.e., they will have had the "append" algorithm executed to produce the final URI. ****** Again, the plan is to incorporate this into ED 07 to close this issue, so please send feedback on this proposal as soon as you can. =Drummond --------------------------------------------------------------------- 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]