I have a use case where there needs to be a parent form that will contain a number of children sections. Now I know I could just have one giant schema and have all of these child sections as subforms, etc. However, I'm trying to make use of fragments as they seem like they might be a decent fit here. However, I keep running into snags. Here are the issues I'm seeing:
1) When I submit the form in Workspace, none of the data entered into either fragment is captured in the XML
2) When I attempt to drill down within formData (the process variable holding the form's data after submission) in Workbench's XPath Builder, it's not picking up any of the elements within any fragment. I have these fragments each bound to a schema and I'm including these schemas in the parent form's schema as well.
Here are my questions:
1) I've read that fragments need to use relative binding to work properly with data capture but that's a bit ambiguous to me. I understand what is meant by "relative" but could someone provide a specific example of what this looks like in Designer when binding a field?
2) How can I get the data elements backing a fragment to show up in the XPath Builder in Workbench? It doesn't seem that Workbench is picking up the inclusion of another schema and allowing me to traverse that tree. This may be due to a lack of understanding on my part about exactly what including another schema is doing.
3) Should I scrap the entire fragment approach here and just wrap these child forms in subform instead and simply have one, massive form with a single schema?
So I have the data being captured now appropriately with one of the fragment's schemas being imported into the parent schema but when I go to update the formData asset in Workbench by editing the variable and clicking "Import Asset", it won't let me save the variable telling me that the XML schema is invalid. Here's the schema:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xs:import namespace="http://www.testing.com/test" schemaLocation="#XFAXSDReference"/>
<xs:element name="EmployeeName" type="xs:string"/>
<xs:element name="EIN" type="xs:string"/>
<xs:element name="DateOfIncident" type="xs:date"/>
<xs:element name="TimeOfIncident" type="xs:time"/>
<xs:element name="RelevantDepartment" type="xs:string"/>
<xs:element name="EmployeeAccidentInjuryForm" type="dhs:EmployeeAccidentInjuryReport"/>
Note that the schemaLocation value has been replaced with #XFAXSDReference" when I actually have it in the schema as the correct path to the schema (and it works in terms of capturing the data appropriately). Also note that the id attribute of the schema element is automatically set to "XFASchemaXSD" despite the fact I already had an id of "testId" specified. If I tweak the parent schema such that the two aforementioned changes don't occur, it accepts the schema just fine so those substitutions done by LC are definitely the issue. Why is that the case? What can I do to get around that?
I should also note that I've ruled out the possibility that the imported schema has errors as Workbench is not showing any issues and, upon form submission, the data is represented properly. As a sanity check, I made the imported schema as simple as possible and Workbench still threw the above error.
It looks like the Fragment doesn't like that there isn't a root node available in its schema. When I just opened the Fragment in Designer, it complained there's no root node. The problem is, I don't think I can have a root node such as an element as it won't let me reference elements from the parent schema - only simple and complex types.
I can't solve your problem as such, but this is how I work with schemas and fragments.
Let's call the main schema main.xsd. You build that schema completely. In that schema, you will have data that you want to bind to a fragment. What I do there, is split this to a new schema, let's call this one fragment.xsd. In your main.xsd, you do an import of fragment.xsd and you make a reference for your element to the complex type you have in your fragment.xsd. The result is the same schema wise.
Now, bind your fragment on fragment.xsd and your form on main.xsd. When you import the fragment, it will have the binding defined already but will act as relative because it has the binding to the smaller schema. It will fit in the big one because of the reference you made.
Let me know if you understand what I mean, otherwise I can make you a sample.