There isn't a concept of a global length of input since some inputs could be streaming and so we don't actually know the length until the end of data is reached.
I guess it isn't clear to me what your data looks like. I /think/ delimited hexBinary should work. If the parent element does not have a length, delimited hex binary should consume all available data up until the end. Could you provide a little more detail on what your data looks like (e.g. what has a known lengths, headers, user data, etc.) As far as implementing lengthKind="prefixed", I don't think the current Daffodil devs have the resources to implement endOfParent right now. Most of us are focused on other tasks at the moment. Tough, it's definitely possible to implement it--there aren't any real technical limitations that I know of with the current code base--but it probably would be a decent amount of work and would be an ambitious tasks for a first time Daffodil contributor. Such a feature touches a lot of different parts of Daffodil so there's a lot to learn. We're more than happy to provide guidance if you do want to contribute this feature, and it probably could be done in reasonably sized chunks, but I'd first want to confirm that there isn't an alternative. - Steve On 1/22/19 10:35 AM, Christofer Dutz wrote: > Hi Steve, > > well the problem is that I don't have the parent length in the current > context. > > Without it, it doesn't seem to work. > > If there was some sort of global variable providing the total length of the > entire input, that would be awesome. > As I mentioned, the length information in in the surrounding protocol, I > wanted to model them all as separate as possible. > > Would it be possible to implement lengthKind="endOfParent"? Would it be a lot > of work? Could I help with it? > > Chris > > > > Am 22.01.19, 15:48 schrieb "Steve Lawrence" <slawre...@apache.org>: > > Correct, lengthKind="endOfParent" has not bee implemented yet. > > As an alternative that we do support, you should be able to use > dfdl:lengthKind="delimited" for the hexBinary user data. In this case, > there's no delimiter, but parent length sort of acts like one. For > example: > > <xs:element name="Parent" > dfdl:lengthKind="explicit" dfdl:length="4" > dfdl:lengthUnits="bytes"> > <xs:complexType> > <xs:sequence> > <xs:element name="Header" type="xs:hexBinary" > dfdl:lengthKind="explicit" dfdl:length="1" > dfdl:lengthUnits="bytes" /> > <xs:element name="UserData" type="xs:hexBinary" > dfdl:lengthKind="delimited" dfdl:encoding="ISO-8859-1"/> > </xs:sequence> > </xs:complexType> > </xs:element> > > So the parent element is 4 bytes and the header is 1 byte. If we parse > the data: > > 0xAA BB CC DD > > We get the following infoset > > <Parent> > <Header>AA</Header> > <UserData>BBCCDD</UserData> > </Parent> > > And the UserData is the remaining three bytes. Using > lengthKind="endOfParent" would probably have better performance if we > implemented it, but this should give the same result for the hexBinary > blob at the end. > > - Steve > > > On 1/22/19 4:16 AM, Christofer Dutz wrote: > > Hi all, > > > > I am stuck with a little problem … I am reading a packet, which is > usually contained inside another. Therefore it doesn’t provide any means of > providing it’s length. > > So the packet is just a small header + binary data … now I want to read > “all the rest” after the header into a field “userData”. > > In the DFDL documentation at IBM I could read that the > lengthKind=”endOfParent” would be what I’m looking for. > > > > Unfortunately this doesn’t seem to be supported … so how can I achieve > the same with implemented options? > > > > Chris > > > > >
