#next: alternate to #replace

["Drummond Reed" <drummond.reed@cordance.net>]

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