Question

XSD reader sometimes returns <missing> values for attribute when unrelated FT with same attribute name is selected as feature path.

  • 29 November 2021
  • 2 replies
  • 4 views

Badge +3

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.

imageimage


2 replies

Userlevel 2
Badge +9

Hi @thijsknapen​ I can confirm that this is not the expected to happen with the XSD Reader. I've submitted a bug report to the developers, and you should get notified once a fix has been released. For your reference the ticket number is FMEENGINE-71498.

Badge +3

Hi @thijsknapen​ I can confirm that this is not the expected to happen with the XSD Reader. I've submitted a bug report to the developers, and you should get notified once a fix has been released. For your reference the ticket number is FMEENGINE-71498.

Hi @danminneyatsaf​ , thanks for looking into the question/case and submitting the bug report. Good to have the confirmation that it is indeed a bug of the XSD reader. Would be good if that indeed can be fixed, looking forward to it :)

Reply