I haven't investigated it much, but my initial thinking is that it's
actually not anything too different from what we already have, so
probably isn't too difficult.
We already have logic for specified length complex elements to set a
length limit for children (using withBitLengthLimit), so new endOfParent
parsers really just need to subtract the current bit position from that
limit to get the endOfParent length, rather than via an expression or
hard coded value. So calculating the length should be fairly
straightforward.
And many of our parsers are abstract classes, so a new endOfParent
parser would just need to extend the right class and implement a new
getBitLength function with the mentioned logic, and it should just work.
Though some parsers take a different approach and use Evaluatables, so
they would need a custom Evaluatable rather than a function override.
And some might even use different approaches as Daffodil has evolved
over time.
I think that is where things get a bit tedious, with just creating all
the parsers that need to use this new logic, and dealing with slightly
different implementation details of the base classes, and adding tests
to make sure all the cases are covered.
I also think there is some complexity in implementing many of the
limitations. There's about a dozen or so cases with this property that
lead to a schema definition error that must be checked for, some are
easier than others.
So algorithmically I don't think there is anything too hard or
different, with lots of reuse being likely. But just the number of
things to implement can get quite large. But this could be done
piecemeal, doing one parser at a time until they are all implemented
(e.g. first do binary numbers, then text numbers, then strings, etc.)
On 1/25/22 1:09 PM, Interrante, John A (GE Research, US) wrote:
I was just looking at this bug yesterday since I'd found it after reading that
Daffodil doesn't implement endOfParent yet
(https://daffodil.apache.org/unsupported/), which'd disappointed me since I'd
wanted to use endOfParent in a complicated DFDL schema I'm trying to simplify
enough for runtime2 to support it (no dfdl:inputValueCalc or
dfdl:outputValueCalc, only dfdl:length=expr at most).
The bug doesn't say how hard it would be to add support for endOfParent for
both simpleTypes and complexTypes. I get it that endOfParent was added to the
DFDL spec only after Daffodil had already been implemented and that endOfParent
was too low priority until now which implies that the work is non-trivial (or
it'd probably have been done as soon as endOfParent was added to the spec).
How hard is it?
John
-----Original Message-----
From: Mike Beckerle (Jira) <j...@apache.org>
Sent: Tuesday, January 25, 2022 7:56 AM
To: comm...@daffodil.apache.org
Subject: EXT: [jira] [Commented] (DAFFODIL-567) lengthKind="endOfParent" for
simpleTypes
WARNING: This email originated from outside of GE. Please validate the sender's
email address before clicking on links or attachments as they may not be safe.
[
https://issues.apache.org/jira/browse/DAFFODIL-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481912#comment-17481912
]
Mike Beckerle commented on DAFFODIL-567:
----------------------------------------
Increased priority, as hacks like delimited hexBinary, with no delimiter
specified, so as to simulate end-of-parent behavior, are proliferating.
One result of the lack of endOfParent, is such time as we do implement
endOfParent, we probably want to make delimited with no delimiter specified (in
scope) an SDE or at least SDW. (I will clarify with the DFDL workgroup if this
is an SDE or not. The DFDL spec is not clear on this. )
However, this will have to be under control of an option/flag because many
schemas may be depending on this delimited-with-no-delimiter behavior.
lengthKind="endOfParent" for simpleTypes
----------------------------------------
Key: DAFFODIL-567
URL: https://issues.apache.org/jira/browse/DAFFODIL-567
Project: Daffodil
Issue Type: New Feature
Components: Back End, DFDL Language
Affects Versions: s7
Reporter: Mike Beckerle
Priority: Major
See also DFDL-238 which is end of parent for complex types.
See also DFDL-566 which is a bug related to end-of-parent
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
