Thinking of it a bit more: I initially wanted to model each protocol layer separately in order to be able to re-use layers. But till now I haven't encountered a single industry protocol utilizing the same protocol twice.
So I'm thinking of joining the three parts (or at least the lower two) into one format definition. Then I have the total length and at least that problem is solved. If Daffodil then starts supporting that feature, I might split it again. Chris Outlook für Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Christofer Dutz Sent: Tuesday, January 22, 2019 5:58:33 PM To: dev@daffodil.apache.org; Steve Lawrence Subject: Re: How to achieve lengthKind=”endOfParent” without using endOfParent? Hi Steve, The code is in the plc4x repo I posted several times now. Unfortunately I'm sitting in a train without my laptop. It's the COTP protocol. There's a matching tdml test with commented out binary payload. That's what I'm trying to read. Could probably post the links some time this evening. Chris Outlook für Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Steve Lawrence <slawre...@apache.org> Sent: Tuesday, January 22, 2019 5:17:24 PM To: dev@daffodil.apache.org; Christofer Dutz Subject: Re: How to achieve lengthKind=”endOfParent” without using endOfParent? 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 > > > > >
