The fn:sum() function is not included in the DFDL specification, and we haven't come across a format that needs it so far, so there really just hasn't been a need to implement it. I'm not sure if the DFDL-WG has a reason for not including fn:sum()--might just be to keep things simple in DFDLv1.0.
In general, I think we've been able to model things similar to what you describe using a combination of arrays, fn:count(), and dfdl:occursIndex(), but it's hard to know for sure if it would work in this case without having the specification. It's not exactly clear to me based on your description. That said, it very well might be cleaner to use fn:sum() rather than fn:count()/dfdl:occursIndex(), so I don't think I would have an objection to a pull request that implemented the function. It would likely be pretty similar to fn:count() (see the FNCount class) except it would require that the type of the subexpression array is numeric and return a sum of the array elements rather than the length. - Steve On 07/17/2018 12:03 PM, Marshall Miller wrote: > Hello, > > We have encountered a data format that requires use of the XPath sum > function, but it appears that this is not supported. > > The data format of interest is the Minefield Data PDU as described by IEEE > STD 1278.1a-1998 section 5.3.10.3. It includes a sequence of integer > fields that describe the number of trip detonation wires for mines > described by the PDU. The values of these fields need to be summed to > determine the occursCount for a subsequent sequence of integer fields that > describe the number of vertices per trip detonation wire. Then these > fields need to be summed to determine the occursCount for a subsequent > sequence of vertices. > > It may also be possible to support this data type with a combination of the > count and position functions but I haven't pursued this enough to know > whether it is feasible for not, and it appears that the position function > is not supported. > > Is there any reason why the sum function is not supported? Do you know of > some other way to support this data type? > > Marshall Miller >
