This is an XPath function and so we'll have to work around it. I've attached an example System to show one way of working around this in EF. For some background, this would all be avoided if each XML object (inside of a large XML document) contained the same tags...even if they are EMPTY. In a perfect world, even if a tag didn't have a value, it would still be present in the XML object. Like this:

• "<tag1></tag1>"; or
• "<tag1 />"

Instead, sometimes the tags are removed (not present; not empty; simply not included). This will lead to the XPath parsing challenge you mention where the previous row's value for that Field will be included as the value for the current Field (as you mentioned in your post).

The workaround is to use 2 Series. The first Series will parse out all the known, standard tags that should be present for each XML object. The second Series will XPath out the XML snippet (inside of the larger XML object) that deals with the XML in question. We will store this XML snippet into a single Field in EF and then pass it down to a second "child" Series for further processing. In order to parse this out in the second "child" Series, we will need to append a root tags around the snippet to make it a valid XML document in it's own right (since XPath will only work in the second Series if the value being passed down is valid XML with a root tag).

The best way to describe the process is to check out the sample System. It's sort of hard to explain it via a forum post.

Example System Notes:

• When the System is Loaded, I'm adding a sample XML document to the "Cars" Series. The zip file contains a screenshot of what the XML looks like in a Word doc...can't C/P into these forum windows). You can also see this in the Action Parameter for the "AddRow" Action underneat of the SYSTEM>>LOADED Event.
• The XML contains 3 Vehicle objects, and each contains a Name, Type, and Attributes tag.
• Inside the Attributes tag, a Vehicle can have x number of Attributes. Each Attribute is identified by the Attribute tag.
• In the example, the first 2 vehicles both have Location Attribute tags, but the last Vehicle does not. If you tried to parse this all out in one Series, the last row in the Series, which is associated with the last Vehicle, would actually have a Location value of the previous rows Location, even though it did not have a Location value to begin with. 
• To get around this we parse out all the known, high-level values (Name, Type) into the first Series, and then create a single Field that will contain all of the Attributes XML for each vehicle. When the row is added to the first Series, we append root tags aroudn the Attributes XML to make it valid XML (so we can do XPath) parsing in the child Series.
• Each Vehicle makes its own row in the first Series, so each row in the first Series is then passed down to the second, child Series. By doing this, we segregate each Vehicle into its own row so it's processed separately, so if there is no XML Attribute value (i.e. Location) for one of the Vehicles, it will just show up as empty, as opposed to copying the previous rows value.

I could go one, but just check out the attached System and see if you can apply this to your workflow. That is probably the best idea.  

Hope this Helps.

-Jack