Hello Russ, Unfortunately these are just packed fields of integers and floats, so we must rely on parsed values to determine exactly which fields are present. It just occurred to me that we could probably make use of choiceDispatchKey/choiceBranchKey to support a limited set of specific values, but that would get messy very fast.
Marshall On Tue, Jul 17, 2018 at 1:17 PM, Russ Williams <[email protected]> wrote: > Hi Marshall! > > I can’t comment on the SUM() function, though it sounds like it’d be very > useful for this case. > > Is there anything in the format which structurally distinguishes the > different data types? If so, you could represent them as unbounded arrays > and use the change of type to determine the end. Obviously that doesn’t > work if they’re all simple integers... > > Cheers, > — > Russ > > > On 17 Jul 2018, at 17:03, Marshall Miller <[email protected]> > 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 > >
