Handle mixed OME/non-OME XML blocks

[curtis]

When looking for OME-XML blocks, Bio-Formats assumes the entire tree will be enclosed in a root <OME> element, with no extraneous root elements or non-OME subtrees anywhere. Ideally, we would like to handle more heterogeneous cases, including:

• Non-OME block after an OME block
• Non-OME block before an OME block
• Multiple OME blocks, and/or multiple non-OME blocks

Obviously, there is not a lot we can do with arbitrary XML from a practical perspective other than ignore it, but for now the goal is merely to avoid throwing an exception in these cases.

[jmoore]

imported from ​bio-formats:#305

[ajpatterson]

Need to consider for validation work in 4.3.2 milestone.

[ajpatterson]

Referencing ticket #6309 has changed sprint.

[jburel]

Referencing ticket #6309 has changed sprint.

[ajpatterson]

Referencing ticket #6309 has changed sprint.

[jamoore]

Referencing ticket #6309 has changed sprint.

[jamoore]

Referencing ticket #6309 has changed sprint.

[mlinkert]

I don't know of any examples of this in practice, and given the age of the ticket am not sure if it would even still be a problem. OK with me to close this, but expanding CC in case anyone else has thoughts (possibly in connection with ​https://trello.com/c/visx1plk/36-schema-samples-migration and/or ​https://trello.com/c/gskA0JKM/65-schema-samples-generation).

[mtbcarroll]

I've no noteworthy thoughts on this but thank you for asking. Perhaps it's significant that nobody seems to have commented further (with any kind of "me/them too", etc.) over the years.

[rleigh]

To some extent, this is already supported I think.

If the OME element is the top-level document element, there can only be one top-level element for it to be a well-formed valid XML document: you can't add elements before or after in this case.

If the OME element is contained as a sub-element within a larger non-OME document, you can have non-OME elements before and/or after the OME element. In this case, you can take the OME element and use this to directly construct a tree of model objects. You could likewise reverse the process to inject the OME elements into an existing document structure. This wouldn't be supported by the existing readers and writers; it would need the user to explictly handle the non-OME XML and then hand over the OME subtree for processing by bioformats inside a custom reader or writer for the extended format in use.

The case which isn't supported at all is a mixed content document where we have non-OME elements interspersed with OME schema elements under the OME element. This would not pass validation though, and I don't think was covered by the cases Curtis mentioned.

I think that to do anything concretely here we would need some scenarios for how it would be used. If custom processing isn't possible inside a specific reader or writer, as mentioned above, is the expectation that the OME-TIFF or OME-XML readers and writers should be able to process such documents?