How to deal with the AASX File Service Interface of Part 2?

admin-shell-io / questions-and-answers

This repository aims for providing answers to often asked questions in the context of the Asset Administration Shell.

https://admin-shell-io.github.io/questions-and-answers/

Creative Commons Attribution 4.0 International

25 stars 6 forks source link

How to deal with the AASX File Service Interface of Part 2? #79

Closed JensMueller2709 closed 9 months ago

JensMueller2709 commented 2 years ago

Regarding the AASX File Server Interface, there are some open questions about the intention of this interface. Following a screenshot out of the AAS part 2 specification document and the link to the belonging Swagger what i´m referring to.

a) Is it just a thought as a simple file server which manages .aasx files without any further functionalities like interacting with the included AAS environments?

b) Or is it intended to combine these interface with the other interfaces? For example to interact with the included AAS environments? This would mean that each call needs to be related to its associated aas package id e.g. POST /packages/{packageId}/shells.

Looking forward to some advice on how to deal with this interface. Thanks for your support!

StenGruener commented 2 years ago

Hi Jens,

a) IMHO you are right and these apis are thought to be used for servers that just "host" the AASX files and serve them. Also probably it is intended to mostly upload and update packages. Downloading AASX can also be realized using /serialization resources.

b) imho you could check which AAS are in which package by evaluating GetAASXByPackageId. Personally, I'd disregard this "package" thinking for type 2 AAS, or do you see any advantages of having a parallel "package" hierarchy within the server?

I will check with the group on Monday.

JensMueller2709 commented 2 years ago

Hi Sten, thanks for your fast reply.

Downloading AASX can also be realized using /serialization resources.

Using the /serialization interface for downloading the uploaded .aasx files (or just parts of it) means that a service needs to parse the AASX files (thoughts of mentioned option b)). In my thinking, a single file server (option a)) only supports uploading/downloading the entire .aasx file. Am i wrong?

Personally, I'd disregard this "package" thinking for type 2 AAS, or do you see any advantages of having a parallel "package" hierarchy within the server?

I agree with you. For type 2 AAS the other interfaces are suitable. If a user wants an AAS serialized as an .aasx file, he can use the /serialization endpoint.

It would be nice if you could summarize the group meeting discussion on this topic. It would also be interesting to know if this interface is only for HTTP or also for OPC UA.

Appreciate your support. Best, Jens

StenGruener commented 2 years ago

Afaik the color is blue in the spec = this interface is only for HTTP