3mfEditor option to not reject files with non-required unknown extensions

[jordig100]

Currently when the 3mfEditor finds an unknown namespace it fails the validation. This prevents to validate 3MF containing information in private extensions from vendors, unknown by the consumer.

Suggest to add a new feature, with an option to enable/disable, to change the behavior to just warn of an unknown non-required extension, and continue with the validation. If the extension is required, I think that better still fail.

To places for unknown extensions: model header and .rels relationship for other files in the OPC.

[JimZuber]

That seems like a reasonable thing to implement, although I am a little uncertain of how difficult this will be to implement as right now the editor presumes that all the XML being validated maps to well know namespaces with the exception of a few places where we have some exception handling code to allow private namespaces.

[JimZuber]

Sample files provided illustrated two unrecognized namespace scenarios....

1)A relationship type specified in a .rels file that does not map to a list of well known relationship types. This error is now treated as a warning and this display of warnings can be disable via a checkbox on the GUI front end.

2. XML content in model file from a private namespace which generated the following error...

Invalid content was found starting with element '{"http://schemas.hp.com/3dmanufacturing/partoptimization/2019/04":optimization}

Schema validation errors that fit this pattern where the names space listed in the error message does not map to a list of well known namespaces is now treated as a warning and NOT and error. Warning can be disable as noted above

This issue will be closed once an updated 3MF Editor JAR and source code is posted to the github site.

[JimZuber]

As noted in prior comment, this issue has been addressed

[JimZuber]

While the last set of changes to the 3MF editor suppressed on error related to custom namespaces, more work needs to be done. In particular how we want to differentiate behavior between customer namespaces in the code whose namespace prefix is referenced in required extension. I think what we need to do is put together a table that illustrates the user extension scenarios, then hopefully we can find simple "global" ways of detecting the scenario(error patterns in the validators output) and forcing the validation errors to become warning