It should be possible to (de-)select enumeration literals when creating a subschema

Submitted by Josef Kaltwasser on Tuesday, 1 February, 2011 - 16:35
Issue ID
Feature request

I've had many complaints from users about excessive enumerations from which only very few literals were actually used by a service without being able to restrict the enumeration in the subschema generation process. The subschema significantly looses expressiveness without this feature and creates potential interoperability problems. I suggest that the tool alows deselecting unused literals in the schema generation process.

{"changeLogs":[{"date":1528113273097,"statusOLD":"- None -","status":"Fixed","assignedOLD":"","assigned":"jaderberg (22)","priorityOLD":"- None -","priority":"Normal","categoryOLD":"- Select a value -","category":"Feature request","componentOLD":"- Select a value -","component":"Tool"},{"date":1537270241952}]}

Posted by jaderberg on November 24, 2026 Permalink

I have done some more thinking on this and I now agree with previous discussions between Josef and Bard on this topic, that this can be solved with documentation.
To summarize my conclusion:
If you make a sub schema and restricting enumerations there will be no problem on the server side because you still publish/send information that is a valid sub set of the whole schema. On the client side you can implement the whole schema or just the sub schema. As a general practice in web service development you should implement the schema/WSDL that the server that you are connecting too. So if you are connecting to another service with another sub schema with restricted enumerations you probably implement a new service that can talk to that service. This is also true if you like to use extensions. There is of course possible to implement the whole schema which can talk to any service that has a schema sub set.