RE: #next: alternate to #replace

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

Forget about 'required' for a second. If that is the only issue we have I will be happy to drop it. The use case for it is that sometimes it is unsafe to interact with an endpoint if its attributes are known. It is the only way to "break" client from trying out talking to an endpoint they *think* they understand but that requires an additional add-on. This came up in OAuth discovery for requiring certain crypto extensions (that without would not be secure enough). This is not a blocking use case.

Back to the main issue.

I don't see how this is not just an include? A client looking to learn about the resource attribute must still load and process each #next XRD. If I want to write a client that loads XRD information into memory, and then query that information as needed later, I will need to load multiple XRD documents, process them, combine the information into another flat container, and then search that.

If there is only one XRD, I can just use the XML document object as my memory store. As soon as I have attributes coming from multiple documents, the client gets more complex. It doesn't matter if it is two or two hundred chained XRD.

Most XRD will be processed in three phases:

1. Load into memory
2. Review for known attributes (Type, XRD-level stuff)
3. Link selection

#see-also and #next work well for #3 because the client *knows* what it is looking for and can stop as soon as it finds it. So it can load one document at a time, search it, and move on. They don't work for #2 without going through *all* the documents.

The real question is how important is the include use case. If it is a critical feature, then the cost on clients doesn't really matter. It is just the cost of doing business.

EHL



> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Thursday, September 17, 2009 6:40 PM
> To: 'XRI TC'
> Cc: Eran Hammer-Lahav
> Subject: #next: alternate to #replace
> 
> In today's (sparsely-attended) telecon we made a crucial decision to
> remove
> #see-also links between XRDs in favor of #replace links.
> 
> The rational was simple: this is the only XRD linking model that lets
> us
> keep the XML processing very simple: just load the XRD into an XML
> parser,
> query its elements/attributes as needed, and get on with your business.
> There is none of the "include" functionality that #see-also implies.
> With
> #replace links, an XRD consumer simply checks at the start of XRD
> processing
> to see if there is a #replace link. If so, it replaces the current XRD.
> If
> not, it knows it has only one XRD to look at.
> 
> I've been cooking on it since the call, and I feel uneasy about this --
> not
> because it doesn't produce a cleaner, faster XRD processing model, but
> because it prohibits what I believe will be a very common XRD
> delegation
> pattern: having a "local" XRD that specifies certain common links an
> author
> might want to have very tight control over, but which then delegates to
> a
> "hosted" XRD to handle everything else. Typical example: a blog owner
> that
> wants to control certain resource properties and links from his/her own
> local blog XRD (for instance the mgmt interface might be right inside
> WordPress), and then delegates to an XRD host like Google or Yahoo for
> everything else.
> 
> #replace does not support that model.
> 
> So here's an alternative I'll call #next. #next does NOT have include
> semantics.  Instead it's "goto" semantics, i.e., an XRD consumer simply
> follows sequential processing of the elements in the first XRD element
> if/until it encounters a #next link (it doesn't even have to look ahead
> through the XML tree to see if there are any #next links). Once it
> encounters a #next link, at that point it stops and loads the linked
> XRD,
> confirms it is valid, and continues processing from there (and DOES NOT
> ever
> backtrack again to the previous XRD).
> 
> The only thing the #next processing model requires is an adjustment to
> processing of required Type elements. There are two options for this:
> 
> 1) Drop the "required" attribute on Type. What is the use case for
> this?
> Should XRD discovery really halt if an XRD consumer does not understand
> a
> particular Type? Or can this form of type-checking be handled at the
> application layer?
> 
> 2) If we keep the "required" attribute on Type, then make it apply per-
> XRD.
> By this I mean that the XRD processor only looks at required <Type>
> elements
> on a per-XRD basis. For example, if it does not find a required <Type>
> element it does not understand in XRD #1, it processes it. Then, if it
> encounters a #next link, it moves to XRD #2, and applies the same rule.
> It
> stops only if it encounters an XRD with a required <Type> element it
> does
> not understand.
> 
> All this means is that if there is a required <Type> that applies to a
> resource in all contexts, then it must appear in all XRDs that describe
> the
> resource. That does not seem like an unreasonable requirement for XRD
> providers at all, especially if that's all we need to do to preserve
> the
> ability to delegate an XRD without giving up all local control.
> 
> In sum, #next preserves the ability to walk a directed graph of XRDs,
> moving
> from each to the next, without having to complete replace each one. Of
> course it also gives us #replace semantics if the only link in the
> source
> XRD is a #next link.
> 
> BTW, I agree with Eran that the rule should be: multiple #next links
> are
> allowed but are only processed if the previous #next links fail to
> produce a
> valid XRD. Otherwise they are ignored. This keeps it simple.
> 
> Thoughts?
> 
> =Drummond