mbeckerle commented on code in PR #98: URL: https://github.com/apache/daffodil-site/pull/98#discussion_r1035000296
########## 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: Right now, our infoset objects store an ERD pointer in each infoset item. This makes it possible to point at any one item, and interpret it correctly (e.g, convert that one item to XML for visualization/debug) because you can indirect over to the ERD to get all the static info. But this takes up space, and in most cases, what ERD is needed for a child item is static information of the enclosing parent, so could be information stored only in the parent item's ERD. And inductively then, most infoset items would not have ERDs stored in them, rather the ERD "nest" is all static info. That's the idea I was exploring. Can we get rid of infoset items carrying ERD pointers? -- 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]
