Where possible, all Inspectors try and traverse their parent first to pick up any useful attributes such as @label. I tried having MetaInspector do this too.
It has the advantage that something like XmlInspector's metawidget-metadata.xml doesn't need to declare the whole path for cases like FooController/foo. It can just do...
<property name="theFoo" type="foo">
The problem is all Inspectors must act the same: I can't remove the parent lookup from all the other Inspectors, because they may be used independent of MetaInspector. Therefore, we have MetaInspector doing the parent lookup and then all the child Inspectors doing 'parent parent' lookups.
Also, having found the parent, traversing from the parent to the child generically is horribly inefficient, as the best we can do is create a DOM and look for its child. We cannot, say, use JavaBean calls to adjust the objToInspect.
Both of these problems can be worked around (at the expense of increasing the complexity of the Inspector API) by introducing a separate inspectParent method, and this has some interesting advantages.
For example when using manually overriden widgets, we don't want to inspect children - we only want to grab some parent details. But now we are looking at an Inspector API with both an inspectParent and an inspect method, where the latter inspects both the parent and the child. I feel this overlap would be confusing for Inspector implementors.
We could try inspectParent and inspectChildren methods, but then the normal case of inspecting both parent and children needs double the calls into the Inspector layer, and would have to return ill-formed chunks of inspection-result.xsd.
On balance, I've decided to keep the Inspector API simple (eg. just inspect) at the expense of a slightly more complicated metawidget-metadata.xml and slightly less efficient manually-specified widgets, because both of the latter cases are used much less frequently than the first.