Semi-structured data

I think that, from the perspective of a component (== "chunk" of code meant for reuse) writer, the world outside their component is semi-structured data: the component writer may assume some sort of structure, but they cannot assume that structure exclusively.

On a parallel note, suppose one writes code that finds the first common manager of two employees in Active Directory. Would anything essential change if the organizational structure were kept in an XML file? In fact, is the core of this solution any different from that for finding the first common parent folder of two files? Or first common parent of two classes in a single-inheritance object-oriented type system?

Active Directories, XML files, file systems, a graph of classes and their inheritance relationships are, to my understanding, examples of semi-structured data.

If our developer were able to cheaply (==effortlessly) use an abstraction over such data, would reuse be enhanced?

I'm currently reminding myself of Self and naming services in open systems. I believe there is a connection between the concepts (...and I bet others do, too). Now, if there were a "by default" available entry point into a semi-structured world - say, a Self-like object - how would a component writer describe their assumptions over that world? Like, say, in our example, the presence of a unique navigation path to "parent"/"container" objects?

Would something like XPath/XQuery help - or, programmatically, LINQ?