There are 2 seperate issues here: 1) Is DFDL a declarative language?
2) Is DFDL a data format description language. I think Mike addresses question (1) rather well. I would just add that, in my opinion, DFDL has some far less declarative components, namely discriminators and complex DPATH expressions (simple assertions and expressions I can see as declarative though). The second questions seems far easier to address. dfdl:encodingErrorPolicy has nothing to do with data formats, and everything to do with parsers. If you look closely at the spec, you will see many places where DFDL is actually about defining (un)parsers specifically, and not data formats generally. For another example, consider multi-values delimeters. As a data format description language, there is no problem in having these. A format with a multi-valued delimeter simply has multiple valid encodings for the same data. However, DFDL goes a step farther and defines a canonical delimiter (the first on in the list). This detail tells you nothing about the format itself, but it does specify how unparsers are supposed to behave. ________________________________ From: Beckerle, Mike <[email protected]> Sent: Monday, November 25, 2019 12:07 PM To: [email protected] <[email protected]> Subject: Re: Assert: DFDL is not a pure descriptive language! This is kind of hard to address. The question strikes me: Is this a matter of choice of terminology? Consider: The behavior of the "+" function given 2 and 2 as arguments is to produce 4 as the total. Vs. 2 + 2 is 4. They are equivalent, though the first sounds less declarative, it really isn't. I just used the words "behavior" and "produce" instead of "is" or equals. How a function "behaves" is fair game to me. Contrast to: Place 2 into register 1, place another 2 into register 2. Add registers 1 and 2 together placing the result back into register 1. My third thing here is clearly still a description. But descriptions fall on a spectrum of declarative to operational, and this 3rd one is way over on the operational end of the spectrum. It is fundamentally less attractive because of how much it over-specifies the way things are done. But another dimension of this issue of language quality is illustrated by this: z = f(x, y) where when f-policy property is "add", f means add, but when f-policy property is "sub", then f means subtract. Is describing function f, via analysis by cases, and by using a separate controlling contextual property somehow fundamentally less declarative? I don't think you have a choice but to do things this way once the functions get complex enough. Decomposition into cases, and separate contextual parameterization feels necessary to control the complexity. In this situation, you need to refer to the different parts of function f, and "behavior" is certaintly one of the best words for separating out the part of function f you want to refer to. Looking at your specific case, dfdl:encodingErrorPolicy is simply a contextual parameter to the function that converts representations of text into text characters. This function is part of every conversion of textual representation to value. You either produce a value or a parse-error. The fact that all parsing lives in a higher-order context which deals with the error/fail cases as well as the successful value-producing cases is pretty much unavoidable. Whether I use words like "behave" and "produce" doesn't fundamentally change things from declarative to operational. Anyway, that's my thoughts on the subject. ________________________________ From: Costello, Roger L. <[email protected]> Sent: Saturday, November 23, 2019 6:51 PM To: [email protected] <[email protected]> Subject: Assert: DFDL is not a pure descriptive language! Hi Folks, DFDL is a language for describing data formats, right? Well, it is that. But, I will argue, it is not purely that. It is muddied by other stuff. Here’s how so. Consider DFDL’s sub-language for describing how data formats escape data. With that sub-language you can describe what a data format’s escape character(s) are and what character(s) escape the escape characters. Good. That is pure descriptive. But, as Steve pointed out this morning, DFDL also has dfdl:encodingErrorPolicy which is most definitely not describing any aspect of data formats. In fact, look at what Steve wrote: The dfdl:encodingErrorPolicy determines the behavior of Daffodil when there's an encoding problem. Unfortunately, Daffodil currently only supports "replace" and not "error". Note what I highlighted in yellow … the behavior of Daffodil. That’s not descriptive. It’s an instruction to Daffodil. One could imagine a description of a data format being used in some other way, by some tool other than Daffodil, and in which behavioral instructions are meaningless. Assert: mixing instructions to a tool into a description language is bad. Surely, at a minimum, it destroys the beauty of the descriptive language. Do you agree? I welcome your comments. /Roger
