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.
Shall the extensions be re-saved, if the editor does not understand them? IMHO it is safer NOT to do that.
Do we want to introduce another attribute indicating to the editor to preserve the extension data even if it does not understand the extension? In that case it would be the responsibility of the further consumer to verify consistency of the edited data with the extension data.
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.
Do we want to specifically disable re-saving OPC relationships that are not marked with MustPreserve?
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.
Do we want to the editor to drop the Metadata marked with preserve=false if it does not understand it?
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/
How shall the consumer / editor handle minor extensions in the spec? Shall it just keep quiet and open it?
How shall the consumer / editor handle major extensions in the spec that may influence the way how the data is interpreted? Shall the consumer / editor warn the user that she / he may not see the full picture?
Do we plan for a breaking change in the 3MF core specification? Shall the consumer / editor refuse opening a 3MF with core or extension version with a major version higher than it understands?
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.
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.