search

3MFConsortium / spec_core

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

Handling of unknown ContentTypes is unclear #3

Closed martinweismann closed 6 years ago

martinweismann commented 6 years ago

Hi all,

we found that the handling of arbitrary “non-standard” content types in 3MF is unclear. (This thread is related to, but more general than Jordi’s “Redundant ContentTypes for textures”-thread).

Details: A first read of the core-specification can lead to the interpretation that non-standard content types are not allowed by the 3MF Core Specification. However, one of the fundamental features of 3MF is that it is extensible. This is partly based on allowing arbitrary content types and relationships other than the ones defined in the core specification.

The most relevant parts of the 3MF core specification are:

  1. “The payload includes the full set of parts required for processing the 3D Model part. All content to be used to manufacture an object described in the 3D payload MUST be contained in the 3MF Document. The parts that can be found in a 3MF Document are listed in Table 2–1. Relationships and content types for these parts are defined in Appendix C, “Standard Namespaces and Content Types.” Each part MUST use only the appropriate content type specified in Appendix C.”

  2. C.1 Content Types 3D Model application/vnd.ms-package.3dmanufacturing-3dmodel+xml PrintTicket application/vnd.ms-printing.printticket+xml

  3. Table 2-1: 3MF Document parts … 3D Model Contains the description of one or more 3D objects for manufacturing. Package REQUIRED … Metadata OPC parts that are associated with metadata Package OPTIONAL

  4. “ The names of any non-standard parts that are associated with the 3D payload SHOULD contain 3 segments, using “/3D/Other/” as the first two segments. “

A first read of these sections can lead to the interpretation that content types other than the two from C.1 are not allowed by the 3MF Core Specification. However:

  1. OPC allows arbitrary MIME media types to associated with file-extensions or individual OPC parts. This freedom is not explicitly forbidden by the 3MF core spec.
  2. Point 4. above provides a hint that arbitrary (non Core-spec) content is actually required in 3MF.
  3. Table 2-1 lists Metadata- and Digital Signature-Parts. Their content type cannot be limited to the two types from C.1 .
  4. Extensibility would be lost: e.g. the content type “image/jpeg” would need to be rejected by any 3MF consumer that does not know about the materials specification of 3MF.

Suggestion: We need to rephrase: “The parts that can be found in a 3MF Document are listed in Table 2–1. Relationships and content types for these parts are defined in Appendix C, “Standard Namespaces and Content Types.” Each part MUST use only the appropriate content type specified in Appendix C.” to be less exclusive or explicitly allow other content types in “C.1 Content Types”.

I will prepare a PR with such a change.

KrisIverson commented 6 years ago

One of the reasons that a content-type for texture was specified was to standardize a minimal set of file formats that producers and consumers needed to support. And to recognize that set as its own well-defined type. This was to ensure that everyone had what they needed to process texture data. We did not want to allow open-ended types that would lead to a situation where a producer provided a format that consumers couldn’t handle. I would not recommend changing this at this point.

Content-type included in the 3MF model file was just an optimization to allow parsers everything they needed to handle a texture file without having to go back into the OPC to look things up. We wanted to avoid OPC handling as much as possible. So, there is some duplication between the content type in OPC, that is used by the OPC parser when deserializing the stream from the “file” in the package, and the content type that is used by the 3MF parser when looking at just the model file. I think that is OK. But would be good to clarify that the content-type must be the same as what is specified by OPC.

I believe 3D Builder has implemented this in the way that was intended; in that the content-type specified is the 3MF texture mime type, with the ext describing the data type. The content-type in the model file matches the ext type.

I agree that the current spec is ambiguous in how ext was written in the spec but was certainly clear that in the requirement that the 3mf texture type be specified.

martinweismann commented 6 years ago

Resolved with https://github.com/3MFConsortium/spec_core/pull/22