I'll add that in this particular case it might be cleaner and more
descriptive of the format to dispatch on the hidden signature rather
than the text description of the signature. Nothing wrong with
dispatching on elements in a hidden group:
<xs:choice dfdl:choiceDispatchKey="{ xs:string(./Hidden_signature) }">
<xs:element ... dfdl:choiceBranchKey="267" />
<xs:element ... dfdl:choiceBranchKey="532" />
<xs:element ... dfdl:choiceBranchKey="263" />
</xs:choice>
On 1/30/19 12:41 PM, Beckerle, Mike wrote:
>
> There's an important DFDL spec erratum about this.
>
> (Errata doc is https://redmine.ogf.org/dmsf_files/13384?download=)
> <https://redmine.ogf.org/dmsf_files/13384?download=>
>
>
> This was a change to the DFDL specification. Turns out lots of formats
> there's
> multiple choiceBranchKey values for the same branch, so we allow this to be a
> whitespace-separated list of identifiers now.
>
>
> That means dfdl:choiceBranchKey="two words" means two different keys "two"
> and
> "words". If you want a single key "two words" you must use a DFDL entity %SP;
> to
> replace the space as you have in your working example.
>
>
>
>
>
> --------------------------------------------------------------------------------
> *From:* Costello, Roger L. <[email protected]>
> *Sent:* Wednesday, January 30, 2019 12:30:35 PM
> *To:* [email protected]
> *Subject:* RE: Two ways to express a choice ... are they equivalent? One
> preferred over the other?
>
> That is an awesome, awesome answer Mike. I sense that you are elaborating a
> key,
> fundamental truth of data formats.
>
> [It is fun digging into data formats!]
>
> While I’ve got you on the line (so to speak), may I ask one more, related
> question, please?
>
> Below are two versions that use choiceDispatchKey. The top version succeeds.
> The
> bottom version fails with the error “dfdl:choiceBranchKey value (this) is not
> unique across all branches of a direct dispatch choice.” Why is that? I don’t
> understand why the branches are not unique?
>
> *From:* Beckerle, Mike <[email protected]>
> *Sent:* Wednesday, January 30, 2019 12:11 PM
> *To:* [email protected]
> *Subject:* [EXT] Re: Two ways to express a choice ... are they equivalent?
> One
> preferred over the other?
>
> Yes,
>
> Always prefer choiceDispatchKey to use of discriminators.
>
> Why? Because it is more declarative of the nature of the data format.
>
> And, because of that, it will result in faster performance for parsing.
>
> Consider that use of choiceDispatchKey expresses that there is a uniform
> mechanism by which the choice branches are selected, and that it is
> independent
> of what is in those branches. This simply gives us more information about the
> data format.
>
> The discriminators in your branches happen, in this case, to be pretty
> uniform
> in structure, and pretty uniform in their placement in the schema. But there
> is
> no reason they have to be. Use of discriminators allows for
> content-of-the-branch-dependent decision making. Each discriminator is an
> entirely independent expression that could do anything.
>
> Inferring that there is any uniformity to the way the branches are
> determined,
> requires looking at the discriminators for each of the branches, wherever
> they
> are (which could be deeply nested, not necessarily in the obvious spot), and
> identifying that they share a common "pattern" of behavior in their
> expressions.
>
> When something is being uniformly done across N branches in a common fashion,
> you want to write that once, not N times.
>
> Also the discriminators are error prone. What if you forget one of them? The
> schema is still well-defined. It just means something different. Doesn't
> describe the same format anymore. The branch missing the discriminator can
> now
> be "not selected" due to a parse error on that branch. Causing this choice to
> backtrack, instead of an enclosing one.
>
> So choiceDispatchKey is *always* preferable.
>
> It is fundamentally superior, more declarative. Simply captures more
> information
> about uniformity and consistency of behavior in the data format that
> discriminators don't express.
>
> --------------------------------------------------------------------------------
>
> *From:*Costello, Roger L. <[email protected] <mailto:[email protected]>>
> *Sent:* Wednesday, January 30, 2019 11:47:25 AM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Two ways to express a choice ... are they equivalent? One
> preferred
> over the other?
>
> Hello DFDL community,
>
> In the Windows EXE file format there is a portion of the file called the
> Optional_Header. Its first field is a “signature” field. The value of the
> signature field indicates whether the file is a 32-bit EXE file, a 64-bit EXE
> file, or a ROM image file:
>
> *If the signature = 267 then
> it is a 32-bit EXE file
> else if the signature = 523 then
> it is a 64-bit EXE file
> else if the signature = 263 then
> it is a ROM image
> else
> error*
>
> Below are two ways to express the choice. Are the two ways equivalent? Is one
> way preferred over the other? Is there a third way to express the choice?
>
