[quote user="Paul Connelly"]"External schema" means the ECSchema is not stored in the .dgn file. Instead it must be located at run-time, e.g. in some directory on the file system. This is what your 56ff0001 handler ID means. You need to tell ECObjects where to find your ECSchema.
[/quote]
This probably explains why I get messages about a "missing" schema file in the Message Center. I did go back to the "source" model and see the issue exists there. On elements that use 0x56FF0000, they work as expected, elements using 0x56FF0001 don't. Since I was the one who "tagged" the data originally, I'm not sure why some got tagged as "internal" and others as "external" (didn't even know there were "internal" verses "external" ones).
[quote user="Paul Connelly"]The alternative (and generally preferred approach) is to store the ECSchema inside the .dgn file such that it can always be located. This is what your 56ff0000 handler ID means. ECObjects will find stored ECSchemas automatically by reading them from the .dgn.[/quote]
This is what I *thought* I was doing all along, but clearly not. In looking at the two sets of data, I see that even though the two elements are supposed to have the same properties, the "size" is different (probably due to one being "internal" and the other "external"). Since I know the schema is already "internal" (as evidenced by *some* of the elements displaying as expected in Element Information), I'm wondering if there is a way to "update" those "external" tags to be "internal" ones. If I can somehow "read" the external tag, I can use it to created an "internal" tag and replace the current one with the new "internal" tag.
Any ideas on how to "read" external tags? When using XmlInstance, the XmlInstanceAPI only seems to read the 0x56FF0000 (internal) entries....