Hi Folks, The idea behind DFDL is to _describe_ a data format using a formal language (the DFDL language). That description is handed off to a tool (a DFDL processor) which understands the DFDL language. Also, an instance of the data format is provided to the DFDL processor. The DFDL processor uses the description to figure out how to parse the instance document. The DFDL processor creates an in-memory representation of the instance document. Then, depending how you configured the DFDL processor, the in-memory representation is serialized (output) as XML. Or JSON. Or EXI. Or some other form.
The description is declarative. It states _what_ is the structure of the data format. (Get a data format SME to help with the description of the data format.) The description doesn't say _how_ to parse the data format. The DFDL processor figures out how to parse the data format using the description of its structure. Plus, the same description that is used to _parse_ the data format is used to _unparse_ the XML (or JSON or EXI, etc.): data format --> DFDL (parse) --> XML --> DFDL (unparse) --> data format That is brilliant! ------------------------------------------------------------ Seek your insights: I am about to send the above message to some internal folks to get them excited about DFDL. Is there anything you would add to the above message? /Roger
