-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reasoning behind maxOccurs="unbounded" on sequence in requirementsType #344
Comments
Don't we need I personally feel we should be replacing all |
|
Ah yes - I mis-read and thought you meant the |
We had this discussion before. My XSD validator (xmlspy) says 'any' is not valid XSD in that situation. |
@berlotti The // Update, I think if we wanted to replace the |
The On the main topic, I think you're right, @NiklasPor. I don't see any reason for having Attaching sample file: |
To solve this, we could we leave xs:sequence (because: #175 (comment)), but remove: |
How about using: |
As many of you probably know, the order in which facets appears in applicability is predefined. On the first glance this is the same for the requirements, but it's not as easy as it appears.
Notice that on the xs:sequence we have
maxOccurs="unbounded"
this enables the sequence to be repeated as many times as we want to. Combining this with optional elements inside the sequence, it's now possible to have ids files with orders which look different, but still are compliant.This makes it not only possible to repeat the entity facet more than once inside the requirements, but also enables the user to ignore the ordering of the
xs:sequence
:Audit runs fine:
ordering-test.ids.zip
I think this is rather confusing for the implementer / user. Inside the
applicabilityType
the order is required and enforced. Inside therequirementsType
it look on the first glance like it's supposed to be ordered (xs:sequence
) while in reality you can use any order.As it was an explicit decision to use
xs:sequence
to "produce the text version of the content in a reliable and consistent way" (comment from @CBenghi ) I think it would be favorable to remove themaxOccurs="unbounded"
from therequirementsType
once the next breaking & major version of the schema is released.If I'm missing any reason for the
maxOccurs="unbounded"
please tell me, I could not find anything while searching through issues & docs. Thanks for taking the time to read through this 👋The text was updated successfully, but these errors were encountered: