Mapping to multiple destination xml forms does not work

[patdunlavey]

@DiegoPino found, while investigating this issue #23, that while it is possible to designate different xml forms as ingest destinations for webform fields, it does not actually work when the ingest preview form is submitted.

This begs the larger question of whether it is necessary to support this case: ingesting to more than one xml datastream. In manual ingestion through the UI, you can only populate data in one xml datastream. (Normally, something like the MODS to DC xslt would then be used to populate the DC datastream from MODS.)

So I'm looking for feedback: Would it make most sense to require the person editing the webform settings to select one xml datastream to use for all field mappings? An implication in this decision would be that any existing IW-configured webforms would need to be updated. An automated update when the preexisting webform uses only one destination xml datastream should be possible, but if the webform fields are mapped to different xml forms, we would probably need to have our update hook remove the mappings entirely.

Thoughts?

[DiegoPino]

Right @patdunlavey. Currently, if users choose mappings (webform fields) from two different forms associated to the same DSID we have a slight problem.

The problem we would have here is data being overwritten because we would be submitting two different forms, which would generate two different XML output documents, each one with different form values:

Even when the basic functionality of Islandora does only allow one metadata form to be mapped to an ingest steps workflow i have done multi metadata workflows possible in the past (https://github.com/DiegoPino/islandora_more_metadata_xml_forms) but always pointing to different DSIDS. So ingesting to multiple XML files is right now possible in IW, but ingesting from multiple XML forms mappings to the same dsid is what we need to resolve.

But nothing is lost:

• one solution is what you suggest, but it means existing forms would need an update, i'm not completely sure if this is good or bad.
• Another solution is to make a nested update case. It's more resource/php heavy but possible. Basically we would reinject the previous document(output) from a form into the submit process of the second one. So the second one would be starting with data already submitted by the previous one. We would need a way to explain this process to admin. One way is to make, in case of multiple form to one DSID, a multistep workflow. Means we show the admin the first form, he submits that one, then we show the admin the second one (pointing to the same dsid), this one would already have the previously submitted values + the ones from the webform field.
  • We could, instead of mapping webform fields to xml form fields, map webform fields to real xpaths. Means the destination inside the XML document. This is even more complicated (means to process every xml form actions (read, update,delete,create) and work directly with those on the xml document. But also a lot more powerful.

Anyway, all methods need testing. I would suggest by putting a documented warning about this, before making changes to the code. We can work on this as an improvement in the long run, it's an edge case anyway.

[patdunlavey]

Thinking about this a bit more, I'm not sure it actually makes sense to retroactively force resetting the field mappings. They will be no more broken than they are already, and in the great majority of cases there is no problem. So I think the sane solution here will be to institute the restriction to a single destination MODS datastream.