Hi folks,

When working with XML files, often I find it really usefull to be able to use the XSD reader to directly structurize the XML in FME feature types, AND to be able to use the known XML schema to generate the correct schema (attribute names, list elements, data types etc).

However, when working with the XSD reader, I noticed something peculiar, which I think might be a bit of a bug.

The thing is, when you select a feature path, FME will generate a feature type with all attributes/lists that are contained at that path.

What I think is quite nice and usefull, is that when you select both a feature path and a subpath of that feature path, the attributes/lists that belong to the subpath, are not included in the feature type of the parent path.

So in my case, when I select only 'msg:GMW_PPO' for the feature path, the feature type contains all contents of that feature path, including a list attribute for the subpath 'msg:GMW_PPO/msg:monitoringTube'.

If however I select both 'msg:GMW_PPO' and 'msg:GMW_PPO/msg:monitoringTube' as feature paths, I get two feature types, where the feature type of GMW_PPO doesn't include a list attribute for the monitoringTube, since the content of the monitoringTubes is already present in the other feature t ype.

So far, so good.

The problem I seem to have found, is that when I select two (from my point of view) unrelated feature paths, I would expect to get the full data. But unfortunately it seems to me that in case there is an object/attribute name that occurs in both these feature types, in one of the feature types this recurring attribute name is sometimes returned with a <missing> value.

So again maybe an example.

If in my case I select the following two feature paths;

1) msg:GMW_PPO

2) msg:GMW_PPO/msg:wellHistory/msg:intermediateEvent/msg:eventData/msg:tubeData/msg:tubeNumber

then I would guess that the list attribute 'monitoringTube{}.tubeNumber' corresponding to the child path 'msg:GMW_PPO/msg:monitoringTube/msg:tubeNumber' is unrelated to the tubeNumber(s) that are returned by the second feature type. But in this case it turns out that that the list attribute 'monitoringTube{}.tubeNumber' always returns with a <missing> value.

I'm wondering, am I overlooking something here, or is this indeed a bit of a bug in the XSD reader?

Kind regards,

Thijs

ps. See below screenshots for more of a visual illustration of the example I described. For those interested, I also included the workspace itself.