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.
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