You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "stevedlawrence (via GitHub)" <gi...@apache.org> on 2024/05/17 18:30:59 UTC
[PR] Allow inputValueCalc to be defined in a hidden group [daffodil]
stevedlawrence opened a new pull request, #1241:
URL: https://github.com/apache/daffodil/pull/1241
An inputValueCalc inside a hidden group behaves very similar to a variable, but is useful in cases where you don't want to use a variable.
For example, a common pattern is two have groups pairs of elements of original data and transformed value. In a subset of cases we may want to hide the original/transformed pair and use an non-hidden IVC that references the transformed value. By allowing hidden IVC's, we do not need change the pattern to use variables.
Only minimal changes are needed because this does not change parse behavior and IVC elements are already skipped during unparsing.
DAFFODIL-2903
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Allow inputValueCalc to be defined in a hidden group [daffodil]
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence merged PR #1241:
URL: https://github.com/apache/daffodil/pull/1241
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Allow inputValueCalc to be defined in a hidden group [daffodil]
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence commented on code in PR #1241:
URL: https://github.com/apache/daffodil/pull/1241#discussion_r1605450428
##########
daffodil-core/src/main/scala/org/apache/daffodil/core/dsom/Term.scala:
##########
@@ -527,7 +527,7 @@ trait Term
e.complexType.group.canUnparseIfHidden
Review Comment:
> I just want to know why the choice case uses the "exists" function?
With a sequence, we must be able to unparse all hidden children. But with a choice, we don't care if there are some branches that can't be unparsed if the choice is hidden--we just need to be able to unparse at least one branch. At this point in the code we don't really care which that branch that is or if there are multiple, we just need to know that such a branch exists. Later we figure out which one we'll actually unparse with if the choice is hidden.
> but what if there are two group members which can be unparsed while hidden (ambiguity),
Daffodil is supposed to just pick the first branch that can be fully unparsed when hidden. There is actually a bug (DAFFODIL-2324) where we incorrectly pick the "more empty" one even if it's not first. But regardles, the answer to the question is w just pick one. I think during compilation we will output a warning so the users know how we are disambiguating.
> or any group member selected by the choice dispatch key field
choiceDispatchKey/Branch is only used during parsing. In theory we could use choiceDispatchKey to disambiguate, but not all choices use choice dispatch, the dispatched branch might not be unparsable when hidden, or the dispatch expression might depend on elements that are hidden. So there's lots of edge cases to consider. It's simplest to just always ignore it when unparsing and use the same logic whether choiceDispatch could work or not.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Allow inputValueCalc to be defined in a hidden group [daffodil]
Posted by "tuxji (via GitHub)" <gi...@apache.org>.
tuxji commented on code in PR #1241:
URL: https://github.com/apache/daffodil/pull/1241#discussion_r1605431742
##########
daffodil-core/src/main/scala/org/apache/daffodil/core/dsom/Term.scala:
##########
@@ -527,7 +527,7 @@ trait Term
e.complexType.group.canUnparseIfHidden
Review Comment:
Just above this case are two more cases, one case which says a sequence term can be unparsed if all of its group members can be unparsed while hidden, and the other case which says a choice can be unparsed if any of its group members can be unparsed while hidden. I'm sure the function is working as it's supposed to; I just want to know why the choice case uses the "exists" function?
```scala
case s: SequenceTermBase => {
s.groupMembers.forall { member =>
val res = member.canUnparseIfHidden
res
}
}
case c: ChoiceTermBase => {
c.groupMembers.exists { _.canUnparseIfHidden }
}
```
If there is only one group member which can be unparsed while hidden, I can see the choice picking that member, but what if there are two group members which can be unparsed while hidden (ambiguity), or any group member selected by the choice dispatch key field which cannot be unparsed while hidden (cannot be defaulted)?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org