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
