In some cases lacunae values and ignoring unknown namespaces will not be enough to recover from errors, for instance because an element appears in the language's namespace that the processor does not know about, or because an element that it knows about appears at the wrong place in the tree.
Again this is a case in which if the rules for processing such errors are not defined, implementations are guaranteed to differ. There are multiple approaches here: flag an error and give up, ignore the element and process what is inside it as if it hadn't been there at all (or process some of it), or ignore the entire subtree contained inside that element.
Deciding which rule to specify can be difficult. In order for a system to be extensible and amenable to versioning, one needs to design it so that it ignores at least some unknowns. But consider a system in which there is an element that is meant to effect a payment, and another one, added later or by a third party, that is expected to cause a service to be rendered. If the payment were effected but the service request ignored with no error being flagged, the processing model is clearly broken. Conversely, if the same message sported an element the intention of which was merely to provide some statistics about purchases, it would be a shame to balk on a perfectly fine transaction for such a triviality.
In a rare concession to elegance, SOAP provides this level of granularity with a
attribute that is used to tell such cases apart.
Yet such a solution won't necessarily apply elsewhere, especially if implementation strategies
somewhat anarchic or if conformance is not readily enforceable. HTML grew to use a system in
unknown elements are ignored but their content is processed. This provides for very useful
strategies, but did lead to some bumps in the road when
were introduced as it caused their content to be displayed in user agents that didn't understand
If in doubt, a processing model (such as SVG's) in which an unknown element is ignored alongside
content (even if that content is understandable) is probably the safer bet. An
aspect for the language designer to consider here will be the exact definition of what
means. For instance in SVG a
rect element found inside an unknown
element will be ignored for rendering purposes (i.e. it will behave as if its
property had been set to
none) but it will still not only appear in the DOM but
Smarter rules, such as SMIL's
switch element always seem appealing at first, but
tend to prove clumsy to use and the granularity and reliability of the testing they offer are
often too low to make them widely useful. I would tend to believe that a
ability would be more useful at the end of the spectrum where compliance is more readily
than at the messier end where most of the Web sits.
Whichever rules you chose are up to you to decide, but if you plan to design a language you have to chose some rules lest interoperability dragons bite your head off, followed closely by hordes of angry users and developers who were stuck reverse-engineering error handling behaviours while their friends were having beer.