3MFConsortium / spec_core

3MF's Core specification
BSD 2-Clause "Simplified" License
55 stars 16 forks source link

specify how editors should handle data they don't understand #43

Closed bubnikv closed 2 years ago

bubnikv commented 3 years ago

We shall strive for making the 3MF format safe to be edited by the editors not understanding the newest 3MF core format, newer versions of the extensions or custom extensions. There is a risk that the editor may produce inconsistent data by combining edits with re-saved data it does not understand, thus confusing the consumers or editors reading such an edited 3MF file, leading to logic errors or crashes.

It is undefined how the editor should behave in case it reads data it does not understand. Should these data be preserved while saving the edited document? Should these data be dropped?

The following has been specified in the core spec:

1) 2.3.1. Support for Versioning and Extensibility. Producers can specify certain extensions as required in a particular 3MF document, in which case consumers that do not support those extensions MUST fail to edit or manufacture that document.

1) 2.1.5. OPC MustPreserve Relationship indicates that Consumers SHOULD save associated parts when modifying the 3MF file even if they do not understand how to process the data. That means, if the part is re-saved, it is up to the consumer reading the edited 3MF file to handle possible inconsistencies between the edits and resaved parts.

2) 3.4.1. Metadata "preserve" Boolean: If set, the editor shall preserve this value when it saves a modified version of this 3MF. Again, it is the responsibility of the consumer reading the edited 3MF to handle possible inconsistencies.

3) 3.4.3.1. Item Element: Part numbers SHOULD be preserved to the greatest degree possible, duplicating them for objects split into pieces, removing them from objects that are combined, and maintaining them for objects that are modified.

The trigger to this issue was the"trianglesets" proposal, which introduces a dependency to the triangle mesh just by releasing an updated 3MF core spec with an increased minor version number I suppose. It is undefined, how the editor shall handle a 3MF specification, being it a core or extension, of a newer version it understands. By adding new nodes to a newer spec referencing data of the older spec may cause the editor to produce inconsistent data in case it re-saves nodes of a specification it does not understand. There is also a risk that the data defined by the spec the older editor does not understand may be crucial to interpret the 3MF correctly.

1) Do we want to introduce some kind of versioning schema, which would guide the older consumers or editors on how to interpret data of a core spec version or an extension version newer that they understand? We may want to implement rules on interpreting changes in major / minor / patch version similar to https://semver.org/

2) Do we want to prohibit re-saving data the editor does not understand, with the exception of the "MustPreserve" marked entities? That certainly makes sense to editors, which parse XML in a streaming fashion. I suppose most if not all of us are doing this for performance reasons anyways, thus we may just canonize it.

3) If we allow the data NOT understood by the editor to be resaved, we need to make it clear to the further consumer that the data may not be coherent. Thus I would rather go with 2). Otherwise one option would be to save some kind of fingerprint into the 3MF file for the consumer to identify that the file was edited and it may not be consistent.

martinweismann commented 2 years ago

can be closed with https://github.com/3MFConsortium/spec_core/commit/4b1b120f689593802d9616f6fcf57dfb4ed7c20e