mhrimaz
commented
11 months ago Furthermore /serialization endpoint only makes sense for full profile and not for separate repositories. The fact that the schema output is an Environment emphasize it.
First if we have only a submodel repository, what should we do with other parameters? what does it even mean to include concept descriptions in the serialization? Why concept description repository also don't accept ids?
What happens?
Currently, RDF/Turtle format is not defined in the
SerializationFormatenumeration list....
Why is this wrong?
Current
/serializationdoes not support rdf/turtle even though the rdf serialization is part of the specification: https://github.com/admin-shell-io/aas-specs-api/blob/a6956e56975c867494ef1d9701444cd2082342a6/ConceptDescriptionServiceSpecification/V3.0_SSP-001.yaml#L268-L282Why in the Chapter 12 only JSON is the only value for serialization format? It should be possible to get any official serialization format and not only JSON. This enables a better integration. For example, Package Explorer works with XML format, so instead of copy-paste json and convert on the background to xml, it can be easily possible to directly import a submodel from a url, then package explorer can try to first get the xml. If the server support different serialization, then the response should be an official serialization, otherwise, the server should return an error. We can also define a specific error for this ("serliaziation format not supported").
How should it be fixed?
text/turtleMIME type should be added as the possible options. Instead of unnecessary restriction that only application/json is allowed in official schema, all possible options should be there....