This is because workspaces in Geoserver have a one-to-one relationship with an XSD schema, while for complex features (that are based on multiple XSD schemas) a workspace should have a one-to-many relationship with XSD schemas.
Currently the unique solution in Geoserver to provide multiple endpoints is the use of virtual services. In Geoserver virtual services endpoint names are inheriting the names of the workspaces which unfortunately are inheriting the name of the XSD schema. Because a complex feature is based on multiple XSD schemas (all INSPIRE complex features are based on base.XSD schema as well) in order to serve an INSPIRE complex feature in Geoserver there will be at least two workspaces, one named base and another named simmilar to the data theme (ex: ps for protected sites) Most complex features have geographical names, and gn.XSD is used in those complex feature types. In this case a data provider can, and therefore he should provide access at two complex features, one bbeeing gn:GeographicalName and the other of the data theme (i.e.: ps:ProtectedSite). In this case already the dataset is composed of two feature types (i.e: ps and gn) and it is based on three XSD files (including base). Therefore, for complex features, the so called workspaces in Geoserver are not workspaces as those entities can be considered only as XSD holders.For complex features a workspace should be based on multiple XSD schemas, therefore a one-to-many relationship should exist between a workspace and the XSDs and not a one-to-one relationship as it is now. As INSPIRE requires a unique endpoint per dataset, so, from an INSPIRE data provider point of view the workspace that is used for creating virtual services should store the dataset. Each such new workspace should have a one-to-many relationship with al XSD schemas used by those featureTypes that are part of the dataset. The endpoint used for the virtual service should provide access to one, many and all toghether featureTypes that are part of the dataset.
Workaround
Do not use virtual services, but create several enpoints by deploying several instances of Geoserver in Tomcat.
This is because workspaces in Geoserver have a one-to-one relationship with an XSD schema, while for complex features (that are based on multiple XSD schemas) a workspace should have a one-to-many relationship with XSD schemas.
Currently the unique solution in Geoserver to provide multiple endpoints is the use of virtual services. In Geoserver virtual services endpoint names are inheriting the names of the workspaces which unfortunately are inheriting the name of the XSD schema. Because a complex feature is based on multiple XSD schemas (all INSPIRE complex features are based on base.XSD schema as well) in order to serve an INSPIRE complex feature in Geoserver there will be at least two workspaces, one named base and another named simmilar to the data theme (ex: ps for protected sites) Most complex features have geographical names, and gn.XSD is used in those complex feature types. In this case a data provider can, and therefore he should provide access at two complex features, one bbeeing gn:GeographicalName and the other of the data theme (i.e.: ps:ProtectedSite). In this case already the dataset is composed of two feature types (i.e: ps and gn) and it is based on three XSD files (including base). Therefore, for complex features, the so called workspaces in Geoserver are not workspaces as those entities can be considered only as XSD holders.For complex features a workspace should be based on multiple XSD schemas, therefore a one-to-many relationship should exist between a workspace and the XSDs and not a one-to-one relationship as it is now. As INSPIRE requires a unique endpoint per dataset, so, from an INSPIRE data provider point of view the workspace that is used for creating virtual services should store the dataset. Each such new workspace should have a one-to-many relationship with al XSD schemas used by those featureTypes that are part of the dataset. The endpoint used for the virtual service should provide access to one, many and all toghether featureTypes that are part of the dataset.
Workaround Do not use virtual services, but create several enpoints by deploying several instances of Geoserver in Tomcat.