Re: XML enables nested error handling

--"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> wrote:

> While I oppose XML because of the patent problem, here is a specific
> example of how XML extensibility would be good.
>
> Proposals to extend SPFv1 to handle optional mechanisms and 'include'
> or 'redirect' mechanisms which might fail all have one feature in
>  common: they specify some sort of test or error trapping, and need
> to delineate to scope of said test or trap syntactically.

Very good point.  I touched on this briefly in my post on 5/22, Ideas for 
semantic (feature) extensibility.  (Hopefully it actually went out to the 
list... I didn't get any replies :)
It turns out that it is possible to add a little bit to the language, and 
get some reasonable fallback behavior using modifiers.  For example, you 
can tell SPF before you get to the include that you want to catch certain 
conditions (like error, unknown, or even pass, fail) and take certain 
actions instead of the default action (like break, continue, error, 
unknown, pass, fail).  It is possible to do this without nesting (you could 
actually use include or redirect as a kind of nesting if you want.)
This kind of logic could be used for multiple things:
 graceful failure or error handling
 skipping over unusable mechanisms. so that the sender can specify the 
fallback
 even including someone else's record and re-casting the results, for 
example "Go look at comcast.net, but what they call "Pass" I call 
"Unknown", and what they call "Fail" I call "Come back and look at the rest 
of my record"
The key to doing this without nesting is defining the behavior well ahead 
of time, and possibly relying on included or redirected records being able 
to specify one fallback position, parse some terms, and then specify a 
different fallback for the next few terms, and so on.

Granted, XML would be one way to make nesting work, and it would be logical 
and easy to understand, but that doesn't give you feature extensibility; 
you still need to do the hard work of defining the fall-back plan really 
intelligently, or letting the user specify the fallback plan.  I am not 
saying either SPF or XML is inherently better, just that we need to do the 
hard work of deciding what to do when unknown mechanisms come along, and 
decide it well ahead of time.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>