RE: [xri] RE: Hole in XRD processing: Type matching

[Eran Hammer-Lahav <eran@hueniverse.com>]

That's basically the same as creating an include directive with all the implementation issues it brings. The main problem is cost to developers to support this feature. Currently, since we only import links and only do so if we can't find what we are looking for, the cost is low. But mandating a pre-fetch is costly and does not come for free from the XML parser (for later iterating through the document content).

EHL

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Wednesday, September 16, 2009 12:29 PM
> To: Eran Hammer-Lahav; 'XRI TC'
> 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
>