To me, this is the canonical example use-case for W3C XInclude. You can store the individual bits anywhere you want on the web, and point (for example) into an element with a @xml:id element on it. There are ways to do more complicated xpointer fragment identifiers, but these aren’t processed automatically in oXygen, my preferred XML editor. oXygen, by default processes XIncludes in this format and so virtually includes the referenced element before validating the file.
So, in your file1.xml where you are encoding an electronic text, you might replace a listPerson element with the following:
<xi:include href="people.xml" xpointer="listPerson1" parse="xml"> <xi:fallback> <listperson> <head>People not available</head> <person/> </listperson> </xi:fallback> </xi:include>
This will include the element which has an @xml:id attribute on it, one assumes a listPerson, stored in the (full TEI file) ‘people.xml’ at that point in file1.xml. Here an optional fallback is provided to provide an empty listPerson with a message inside a head element. One of the benefits of this is that many texts can refer to the same listPerson, listPlace, textDesc, msDesc, or what have you, so you share resources across multiple documents, projects, and hopefully institutions. When projects use such a system, in addition to their editions, their standalone listPerson, listPlace, etc. files should also be made transparently available so that other people can point to the same people, places, etc.