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