[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Hole in XRD processing: Type matching
Eran, I agree this is an important issue. For me there is a certain sense of deja-vu because the XDI TC has dealt structurally with this issue for several years now. I'll take a minute to explain this in case it helps shed some light, then I have a specific suggestion. In the XDI TC's case, every XDI document can describe one or more XDI subjects (in XDI, unlike XRD, an XDI document may describe more than one subject). XDI has always had the concept of synonyms, i.e., multiple XRIs that identify the same subject, either in the same context or in different contexts. XDI synonyms are expressed using the $is predicate. For example (in X3 syntax): =drummond.reed <--XDI subject--> $is <--XDI predicate for synonyms--> =drummond <--synonym from the same = context as the subject--> =!f83.62b1.44f.2813 <--i-number synonym in same = context--> @cordance*dsr <--synonym in @cordance context--> @oasis=drummond.reed <--synonym in @oasis context--> In essence all four synonyms in the X3 snippet above are the XDI equivalent of XRD #see-also links. This means that if those XRIs are rooted in a different context (e.g., @cordance*dsr and @oasis=drummond.reed), then an XDI client can request XDI documents for those XDI subject that may have different predicates/objects describing the same subject. So the bottom line is, whenever you have the capability for distributed descriptors of the same logical resource, you have the capability for inconsistency between those descriptions. One descriptor may say the subject resource is of type "foo", another may say it is of type "bar", and another may not give its type at all. XDI gets around this problem to a certain extent by enabling XDI documents to contain multiple descriptors. So any particular XDI authority could answer an XDI request for a descriptor of, say, =drummond.reed by returning an answer that includes multiple descriptors, e.g.: =drummond.reed $is =drummond =!f83.62b1.44f.2813 @cordance*dsr @oasis=drummond.reed $is$a foo @cordance*dsr $is$a bar @oasis=drummond.reed +email "drummond.reed@example.com" Even though this entire XDI document came from one authority, it includes descriptors from three different contexts. Leaving aside trust issues (each descriptor would have to be signed by its own authority), a consistent aggregate description can be assembled and returned from any authority (or not, as policy dictates). Anyway, I bring all this up because it seems the fundamental issue is one of consistency and completeness of descriptors across contexts. It's a hard problem. But in keeping with the "keep it simple" approach of XRD, here's a suggestion: just as we have a "required" attribute on Type, specifically so that an XRD consumer knows it MUST understand a resource of that type to continue, could we solve this cross-context descriptor consistency problem by adding a "required" attribute on <Link>? If the value of this attribute were "true", the semantics would be: an XRD Consumer MUST retrieve the linked XRD, MUST process its elements in document order, and MUST apply all the same rules (e.g., observance of any required <Type> elements) before XRD processing is considered complete. This way, if an XRD provider knows that a linked XRD is required for proper understanding of a subject resource, the provider can simply list the <Link> element with required="true" in the proper document order to make sure it is processed. =Drummond > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Wednesday, September 16, 2009 10:37 AM > To: 'XRI TC' > Subject: [xri] RE: Hole in XRD processing: Type matching > > If it wasn't clear, this is a blocking issue and we cannot publish another > draft of the spec until it is resolved. > > Will and I had a long conversation about it last night and here are some > additional thoughts: > > * We have two clear use cases: > > - The ability to delegate XRD descriptor for a local resource to another > provider. While this can be done at the links level, we need it to be > signed for trust purposes which means we need the "redirection" to happen > inside a signed document. Since we only have one mechanism to do so (XRD), > we need to express this inside XRD. For example, a site can point > consumers to another company to manage all its XRD needs. > > - The ability to define a local XRD and include in it descriptors from > other documents. This is needed to override or supplement the information > in either the local XRD or the included XRDs. For example, being able to > delegate XRD services to another service which does not support some new > XRD feature, but still add that locally before including the delegated > information. > > Right now, we have a well-defined solution that does not meet the > expectations. See-also links currently only import <Link> elements from > other XRD documents, and anything else in the linked XRD is ignored, > including the <Subject>, <Alias>, and <Type>. <Subject> may be used for > trust verification but undefined for anything else when following a see- > also. This fails both use cases. > > More too follow. > > EHL > > > -----Original Message----- > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > Sent: Tuesday, September 15, 2009 9:32 PM > > To: 'XRI TC' > > Subject: [xri] Hole in XRD processing: Type matching > > > > I brought this up before but I didn't realize how much bigger the issue > > is. > > > > > > Currently, we say nothing about how consumers should treat the see-also > > link in the context of Type matching (as opposed to Link selection). > > Basically, we do not include see-also links for the purpose of resource > > properties, only links. Furthermore, it doesn't address any extensions > > at the XRD level (link extensions are covered). > > > > Consider this: > > > > <XRD> > > <Type>http://example.com/type1</Type> > > <Link> > > <Rel>http://docs.oasis-open.org/xri/xrd/v1.0#see-also</Rel> > > <URI>http://example.com/xrd2<URI> > > <MediaType>application/xrd+xml</MediaType> > > </Link> > > </XRD> > > > > And xrd2: > > > > <XRD> > > <Type required="true">http://example.com/type2</Type> > > </XRD> > > > > In the example above, the consumer will ignore the see-also type, and > > will continue to interact with the resource even if it doesn't > > understand 'type2'. > > > > Another example: > > > > <XRD> > > <Link> > > <Rel>http://docs.oasis-open.org/xri/xrd/v1.0#see-also</Rel> > > <URI>http://example.com/xrd2<URI> > > <MediaType>application/xrd+xml</MediaType> > > </Link> > > </XRD> > > > > And xrd2: > > > > <XRD> > > <Type>http://example.com/type1</Type> > > <Link> > > <Rel>http://example.com/rel1</Rel> > > <URI>http://example.com/endpoint<URI> > > </Link> > > </XRD> > > > > In this case, the first XRD simply delegates its description to another > > XRD. However, this delegation is limited to link selection only which > > means a consumer looking for link of type 'rel1' will not process the > > 'type1' information. This will lead to either incomplete information at > > the time of processing the xrd2 link, or to failing to recognize (and > > hence even look for such link) that the resource supports the 'type1' > > functionality. > > > > --- > > > > None of the options to resolve this are great. This is the list I was > > able to come up with: > > > > 1. Require the parsing of all linked XRDs for the purpose of > > determining the resource attributes (XRD level). This doesn't scale > > well, but might not be too bad since we are talking about building a > > flat list of single values. It also solves the issue of XRD level > > extensions which will also be collected. > > > > 2. Limit consumers to use the types from the first XRD only. This goes > > against the architecture and breaks the main use case for see-also > > which is delegating the entire descriptor. > > > > 3. Make the fetching of linked XRDs for the purpose of resource > > attribute optional, but that conflicts with the use of the 'required' > > attribute. It will create inconsistent behavior based on how a consumer > > obtained an XRD. > > > > What makes <Type> so different from <Link> is that with links, > > consumers know what they are looking for (often thanks to the use of > > <Type>). But with XRD level resource attributes, the whole point is to > > go over the list and discovery what is familiar. > > > > #1 is the only option that is consistent with the architecture but I am > > worries about its implementation. I am not sure what is the right > > solution. > > > > Ideas? > > > > EHL > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to 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]