Retype all order elements to xsd:positiveInteger and fix the associated examples

[skinkie]

This is a breaking change (with respect to the documentation) which mixes xsd:positiveInteger with xsd:integer.

The main difference is: positiveInteger starts at 1.

Please carefully consider the changes that have a mention on "Relative order". No examples exists with a negative relative order, but the design might allow them?

Fix #475

(apply after the required Id pull request)

[trurlurl]

@skinkie No, I cannot be sure about negative order numbers, I'm not sufficiently familiar with the structures in question.

[ue71603]

I think we moved the elevator order into an element. So it means that order is arbitrary. And from N to Q everything can be ordered the same way ;-)

[Aurige]

I agree that we need to harmonise order's type ...
I don't think that negative if the bigger risk (but you never know, you may face people populating order with a lift level), but I'm concerned about 0: you can be sure that a lot of existing data set are already using order=0 when it is defined as an integer... so this means breaking a lot of currently valid data sets.
Why not harmonising the way around (make all orders Integers) ? there is no stake here, except than being able to sort based on the order (we don't care if it is 0 or negative)

[skinkie]

Show me the breaking data.

[Aurige]

Show me the breaking data.

The examples you had to correct ?

[skinkie]

The examples you had to correct ?

The PassengerStopAssignment order should always have started at 1?

[Aurige]

Will be discussed in meeting #14 (October 4th)

[ue71603]

Will be discussed in meeting #14 (October 4th)

Does this mean you are ok with it?

[Aurige]

Will be discussed in meeting #14 (October 4th)

Does this mean you are ok with it?

My mind is not fully made up about it (not against, but don't like its drawbacks)... and anyway whatever I prefer, we need the group validation to accept the drawbacks

[Joostb61]

The RelativeOrder element should remain integer.
The EPIAP documentation recommends to use RelativeOrder '0' for the groundfloor. That's not possible if it is a positveinteger. However it is possible to renumber the RelativeOrder, this is not desirable since it means all levels get a new RelativeOrdernumber if a new underground floor is added.

[ue71603]

@Joostb61 RelativeLevelOrder is not affected. Only the order attributes are concerned.

[ue71603]

@Aurige go or no go from group?

[Aurige]

The group decision was : The PR is accepted but needs to be separated from the IdType fix on which it is stacked
Note: may generate some backward compatibility issues

[ue71603]

@skinkie who will remove the IdType part? Should I rebase it?. Otherwise it was accepted by enough reviewers. Or do you want explicitly have acceptance by @Aurige

[skinkie]

If you only go for the changing or order element, I would cherry pick the specific commits.

[ue71603]

use the last four or so comments. and redo...

[Aurige]

How to express that order (mandatory) is not useful in some cases ? Make it non mandatory ? use value "1" for all orders ?
Value 1 is the group's preferred choice ... to be described in the document/anotation (only when the order is meaningless)

[ue71603]

replaces with #657

[trurlurl]

Removing "documentation update needed" since closed without merging.