Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discriminators misplaced #4

Closed
mbeckerle opened this issue Feb 15, 2020 · 2 comments
Closed

Discriminators misplaced #4

mbeckerle opened this issue Feb 15, 2020 · 2 comments
Assignees

Comments

@mbeckerle
Copy link
Member

mbeckerle commented Feb 15, 2020

I observed that many things with discriminators are coded like this:

<xs:sequence>
    <xs:annotation><xs:appinfo source="http://www.ogf.org/dfdl/">
         <dfdl:discriminator ....../>
    </xs:appinfo></xs:annotation>
  ....rest of sequence...
</xs:sequence>

So, it's quite unintuitive, but that discriminator will be executed AFTER the rest of the sequence.
That is: Daffodil does not hoist discriminators expressed this way so they execute as early as possible. It just does them after.

DFDL was designed to allow discriminators to reach into the model group/complex type where they are expressed, so that they can discriminate on elements within the structure where the discriminator is expressed. These are parse-time forward+downward references as far as the lexical appearance of the discriminator is concerned.

To get the discriminator to run BEFORE the rest of the sequence, which is typically what you want from a discriminator, you must nest it within ANOTHER sequence inside the first like so:

<xs:sequence>
  <xs:sequence>
      <xs:annotation><xs:appinfo source="http://www.ogf.org/dfdl/">
           <dfdl:discriminator ....../>
      </xs:appinfo></xs:annotation>
  </xs:sequence>
  ....rest of sequence...
</xs:sequence>

I am going to suggest that Daffodil issue warnings about the former style (which can also occur on choices), since it is so unintuitive.

But for PCAP, all the discrimnators have to change.

@mbeckerle
Copy link
Member Author

Actually, PCAP should be rewritten to use choices with choiceDispatchKey and choiceBranchKey exclusively. There's no reason for backtracking/discrimination at all in this sort of format.

Using choiceDispatchKey is always the preferred style. PCAP was not done this way initially just because Daffodil didn't have the choiceDispatchKey feature implemented in DFDL at the time PCAP schema was first created.

In general, example schemas should all be revisited for this issue.

@mbeckerle
Copy link
Member Author

Fixed in 86df108

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant