tuxji commented on code in PR #98: URL: https://github.com/apache/daffodil-site/pull/98#discussion_r1036508892
########## site/dev/design-notes/runtime2-todos.adoc: ########## @@ -36,7 +36,108 @@ If someone wants to help please let the mailto:[email protected][dev] list know in order to avoid duplication. -=== Report hanging problem running sbt (really dev.dirs) from MSYS2 on Windows +=== Anonymous/multiple choice groups + +We already handle elements having xs:choice complex types. +In addition, we should support anonymous/multiple choice groups. +We may need to refine the choice runtime structure +in order to allow multiple choice groups +to be inlined into parent elements. +Here is an example schema +and corresponding C code to demonstrate: + +[source,xml] +---- + <xs:complexType name="NestedUnionType"> + <xs:sequence> + <xs:element name="first_tag" type="idl:int32"/> + <xs:choice dfdl:choiceDispatchKey="{xs:string(./first_tag)}"> + <xs:element name="foo" type="idl:FooType" dfdl:choiceBranchKey="1 2"/> + <xs:element name="bar" type="idl:BarType" dfdl:choiceBranchKey="3 4"/> + </xs:choice> + <xs:element name="second_tag" type="idl:int32"/> + <xs:choice dfdl:choiceDispatchKey="{xs:string(./second_tag)}"> + <xs:element name="fie" type="idl:FieType" dfdl:choiceBranchKey="1"/> + <xs:element name="fum" type="idl:FumType" dfdl:choiceBranchKey="2"/> + </xs:choice> + </xs:sequence> + </xs:complexType> +---- + +[source,c] +---- +typedef struct NestedUnion +{ + InfosetBase _base; + int32_t first_tag; + size_t _choice_1; // choice of which union field to use + union + { + foo foo; + bar bar; + }; + int32_t second_tag; + size_t _choice_2; // choice of which union field to use + union + { + fie fie; + fum fum; + }; +} NestedUnion; +---- + +=== Arrays + +Instead of expanding arrays inline within childrenERDs, +we may want to store a single entry +for an array in childrenERDs +giving the array's offset and size of all its elements. +We would have to write code +for special case treatment of array member fields +versus scalar member fields +but we could save space/memory in childrenERDs Review Comment: I've revised this section with a better understanding of how to handle dynamically sized arrays with dfdl:occursCountKind = "expression" and dfdl:occursCount = { ../count }. ########## site/dev/design-notes/runtime2-todos.adoc: ########## @@ -36,7 +36,108 @@ If someone wants to help please let the mailto:[email protected][dev] list know in order to avoid duplication. -=== Report hanging problem running sbt (really dev.dirs) from MSYS2 on Windows +=== Anonymous/multiple choice groups + +We already handle elements having xs:choice complex types. +In addition, we should support anonymous/multiple choice groups. +We may need to refine the choice runtime structure +in order to allow multiple choice groups +to be inlined into parent elements. +Here is an example schema +and corresponding C code to demonstrate: + +[source,xml] +---- + <xs:complexType name="NestedUnionType"> + <xs:sequence> + <xs:element name="first_tag" type="idl:int32"/> + <xs:choice dfdl:choiceDispatchKey="{xs:string(./first_tag)}"> + <xs:element name="foo" type="idl:FooType" dfdl:choiceBranchKey="1 2"/> + <xs:element name="bar" type="idl:BarType" dfdl:choiceBranchKey="3 4"/> + </xs:choice> + <xs:element name="second_tag" type="idl:int32"/> + <xs:choice dfdl:choiceDispatchKey="{xs:string(./second_tag)}"> + <xs:element name="fie" type="idl:FieType" dfdl:choiceBranchKey="1"/> + <xs:element name="fum" type="idl:FumType" dfdl:choiceBranchKey="2"/> + </xs:choice> + </xs:sequence> + </xs:complexType> +---- + +[source,c] +---- +typedef struct NestedUnion +{ + InfosetBase _base; + int32_t first_tag; + size_t _choice_1; // choice of which union field to use + union + { + foo foo; + bar bar; + }; + int32_t second_tag; + size_t _choice_2; // choice of which union field to use + union + { + fie fie; + fum fum; + }; +} NestedUnion; +---- + +=== Arrays + +Instead of expanding arrays inline within childrenERDs, +we may want to store a single entry +for an array in childrenERDs +giving the array's offset and size of all its elements. +We would have to write code +for special case treatment of array member fields +versus scalar member fields +but we could save space/memory in childrenERDs +for use cases with very large arrays. +An array element's ERD should have minOccurs and maxOccurs +where minOccurs is unsigned +and maxOccurs is signed with -1 meaning "unbounded". +The actual number of children in an array instance +would have to be stored with the array instance +in the C struct or the ERD. +An array node has to be a different kind of infoset node +with a place for this number of actual children to be stored. +Probably all ERDs should just get minOccurs and maxOccurs +and a scalar is just one with 1, 1 as those values, Review Comment: I understand what you mean better, and I've added a new "Making infosets more efficient" section with the idea you expressed. ########## site/dev/design-notes/runtime2-todos.adoc: ########## @@ -36,7 +36,108 @@ If someone wants to help please let the mailto:[email protected][dev] list know in order to avoid duplication. -=== Report hanging problem running sbt (really dev.dirs) from MSYS2 on Windows +=== Anonymous/multiple choice groups + +We already handle elements having xs:choice complex types. +In addition, we should support anonymous/multiple choice groups. +We may need to refine the choice runtime structure +in order to allow multiple choice groups +to be inlined into parent elements. +Here is an example schema +and corresponding C code to demonstrate: + +[source,xml] +---- + <xs:complexType name="NestedUnionType"> + <xs:sequence> + <xs:element name="first_tag" type="idl:int32"/> + <xs:choice dfdl:choiceDispatchKey="{xs:string(./first_tag)}"> + <xs:element name="foo" type="idl:FooType" dfdl:choiceBranchKey="1 2"/> + <xs:element name="bar" type="idl:BarType" dfdl:choiceBranchKey="3 4"/> + </xs:choice> + <xs:element name="second_tag" type="idl:int32"/> + <xs:choice dfdl:choiceDispatchKey="{xs:string(./second_tag)}"> + <xs:element name="fie" type="idl:FieType" dfdl:choiceBranchKey="1"/> + <xs:element name="fum" type="idl:FumType" dfdl:choiceBranchKey="2"/> + </xs:choice> + </xs:sequence> + </xs:complexType> +---- + +[source,c] +---- +typedef struct NestedUnion +{ + InfosetBase _base; + int32_t first_tag; + size_t _choice_1; // choice of which union field to use + union + { + foo foo; + bar bar; + }; + int32_t second_tag; + size_t _choice_2; // choice of which union field to use + union + { + fie fie; + fum fum; + }; +} NestedUnion; +---- + +=== Arrays + +Instead of expanding arrays inline within childrenERDs, +we may want to store a single entry +for an array in childrenERDs +giving the array's offset and size of all its elements. +We would have to write code +for special case treatment of array member fields +versus scalar member fields +but we could save space/memory in childrenERDs +for use cases with very large arrays. +An array element's ERD should have minOccurs and maxOccurs +where minOccurs is unsigned +and maxOccurs is signed with -1 meaning "unbounded". +The actual number of children in an array instance +would have to be stored with the array instance +in the C struct or the ERD. +An array node has to be a different kind of infoset node +with a place for this number of actual children to be stored. +Probably all ERDs should just get minOccurs and maxOccurs +and a scalar is just one with 1, 1 as those values, +an optional element is 0, 1, +and an array is all other legal combinations +like N, -1 and N, and M with N<=M. +A restriction that minOccurs is 0, 1, +or equal to maxOccurs (which is not -1) +is acceptable. +A restriction that maxOccurs is 1, -1, +or equal to minOccurs +is also fine +(means variable-length arrays always have unbounded number of elements). Review Comment: I agree, and I've made the "Arrays" section say the normal case should be no validation since Daffodil must not enforce min/maxOccurs if the user wants to parse and unparse well-formed but invalid data. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
