Open NiklasPor opened 1 month ago
Don't we need maxOccurs="unbounded"
so we can have test multiple propeties, attributes etc in a single specification? For entityType is clearly makes no sense as an entity can only be one.
I personally feel we should be replacing all xs:sequence
s with xs:any
. I can see no benefit in enforcing the sequencing of the nodes? My recollection is the decision related to 'implementor simplicity' but as this shows it's creating other issues. (not to mention folks who may edit IDS in an editor without XSD support)
I don't think we need maxOccurs="unbounded"
on the sequence, because all elements inside the sequence have maxOccurs="unbounded"
themselves. So they can already be repeated, but just have to be placed after each other. Check the excerpt from ids.xsd
at the top. The only element without maxOccurs="unbounded"
is the entity facet – so this seems intended. (This is also how it works inside the applicabilityType
where the sequence does not have maxOccurs="unbounded"
.
Yes I'd also favor xs:any. Take a look at https://github.com/buildingSMART/IDS/issues/175#issuecomment-1744634900 where this topic was already discussed. (Although I'd still favor xs:any over xs:sequence)
Ah yes - I mis-read and thought you meant the maxOcurs
on the elements. I agree the maxOccurs on the xs:sequence
doesn't make sense - unless I'm missing something.
We had this discussion before. My XSD validator (xmlspy) says 'any' is not valid XSD in that situation. Happy to take suggestions to change this, as long as XSD stays valid XSD
@berlotti The xs:any
is just a side note, what about the maxOccurs=unbounded
on the requirementsType
?
// Update, I think if we wanted to replace the xs:sequence
we should replace it with xs:all
not xs:any
The xs:all
(and xs:any
) is not suited, I think, because it only allows for one element of a kind (the maxOccurs
can be only 0 or 1 and we need 'unbounded').
On the main topic, I think you're right, @NiklasPor. I don't see any reason for having maxOccurs=unbounded
on sequence
in requirementsType
(L113). We want to be able to have for example: E-C-P-P, but not E-P-C-P. Right now, maxOccurs makes it possible.
Attaching sample file: SequenceTest.zip
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 👋