[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comment on XRI Resolution working draft 9
As described in working draft 9, when you query the authority for the first sub-segment of an XRI, you get back an XML doc like so: <XRIDescriptors xmlns='xri://$res*schema/XRIDescriptor*($v%2F2.0)'> <XRIDescriptor> ...... </XRIDescriptor> </XRIDescriptors> The next sub-segment, let's say it's at a different authority server, delivers a similar document: <XRIDescriptors xmlns='xri://$res*schema/XRIDescriptor*($v%2F2.1)'> <XRIDescriptor> ...... </XRIDescriptor> </XRIDescriptors> The final XML document that the resolver client returns must, it seems to me, extract all the </XRIDescriptor>...</XRIDescriptor> elements, and include them in -one- <XRIDescriptors> element, because there should be one root element in an XML document. But if, as in my example, the different XRIAuthorities return different <XRIDescriptors> versions, which is entirely possible since the upstream authority has no knowledge of what's being served downstream -- what version number to use on the final result returned by the resolver client? A solution would be to remove the version attribute from the <XRIDescriptors> element and give it to the <XRIDescriptor> element. That way, each <XRIDescriptor> in the chain could have it's own version, which reflects the reality that the content of each <XRIDescriptor> has to be understood within its own version context. Another related point is that the <XRIDescriptor> is now described in wd9 as having an xrdi:id attribute. Because the resolver is accumulating XRIDs from a chain of servers, the XRI Authority server must return an xrdi:id attribute that is globally unique. OTOH, since the <XRIDescriptors> element is an -ordered- collection of <XRIDescriptor> elements, is there really any need for the xrdi:id attribute? =vg
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]