I think you are correct. DFDL v1.0 specifically stops with only a single-pass. There is no multi-layer translation capability. Things that require mutliple passes must be modeled using an application that uses DFDL via its API at two levels. In addition, there is no support for base64, or in fact any other encoding scheme, encryption, compression, etc. The only "decoding" done is decoding of a character set encoding to unicode (and back for unparsing). That said, both the things you describe here are, in my mind, high priority for version 2.0 of DFDL, and I fully expect we'll be creating some experimental features in Daffodil to play around with what would be a good solution for these things that is general, extensible, but not going too far, and if successful we'll try to get into DFDL v2.0 for standardization. Encodings like base64, general hexadecimal, and even things like my personal favorite - Ascii85 (of which there are several variations), are pretty similar to character set decoding conceptually. You can't do it with a flat table lookup, but a table lookup + a small recurrence state can do it. Compression and encryption are harder. Those I suspect we're talking about plug-in APIs to the implementations so those can be added. In general multi-layer translation is important in the future because it is so often needed. I have looked at multi-layer parsing in the past. I have hit a wall on multi-layer unparsing. Approaches I've considered, ... they simply feel far too algorithmic, and not particularly declarative. But I haven't given up yet. Just postponed working on it. On Fri, Mar 29, 2013 at 2:12 PM, Garriss Jr., James P. wrote:

The attached PDF file details a feature of email headers known as encoded words. I think DFDL is incapable of modeling this feature, but I’d like to get your feedback. TIA****

-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg

-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com