Upland OL User community

RESOLVED: Repeat step not as expected in data model

#1

Hi,

Let’s say I have a simple XML:

<?xml version="1.0" encoding="UTF-8"?>
<xml>
	<document>
		<jobs>
			<job>
				<current>
					<jobno>60001075</jobno>
				</current>
				<previous>
					<jobno>60002075</jobno>
				</previous>
			</job>
			<job>
				<current>
					<jobno>60001074</jobno>
				</current>
				<previous>
					<jobno>60002074</jobno>
				</previous>
			</job>
			<job>
				<current>
					<jobno>60001076</jobno>
				</current>
				<previous>
					<jobno>60002076</jobno>
				</previous>
			</job>
		</jobs>
	</document>
</xml>

My steps look like this:
image
So, the repeat is on /xml/document/jobs/job

My XML viewer looks like this:
image

And finally my Data Model looks like this:
image

As I defined the repeat to start at job level I do not understand why at the Data Model level I do not have job[3] and current[1] and previous[1] instead it seems to loop over current and previous.

#2

Unless someone else has found a way to do this, I will check with our R&D department if it is an issue or if it is my lack of understanding the XML path inner working.

Request to R&D has been opened under SHARED-89206.

#3

Here’s my version of a DM config that appears to do what you’re expecting:

XMLLevels.OL-datamapper

#4

Thank you both very much for your quick replies.
I do not understand why a separate extraction is necessary on job level for a field in the Data Model that does essentially nothing except making sure that the system somehow understands that there needs to be an iteration over job level instead of separate iterations over current and previous?

Perhaps my understanding of XPath and the Data Model is lacking but I am glad it works and I will apply this in my larger data model to see if it will work there too.

#5

I see what you mean, and I have to admit that the explanation for it is a bit on the subtle side.

A detail table (or a nested detail table) needs to belong to a record, which acts as a container for fields and tables. But that record can only exists if you extract something to it, otherwise it is only considered as a hierarchical marker in the data model (as opposed to a container). In your case, since you are not extracting anything from the job level, each iteration of the repeat loop takes for granted that it is extracting content for the same unique job level.

Yeah… reading myself back, I realize my explanation may just add to the confusion, but trust me when I say that the behavior is by design. Now, whether that design was a good or bad decision is an entirely different question… :stuck_out_tongue:

#6

Your explanation does make sense and as for the design decision I will not comment on that :slight_smile:
Thank you very much for your help