adding CheckConstraint to StopPointInJourneyPattern#1020
Conversation
ue71603
added
the
enhancement
…ersion.xsd Co-authored-by: trurlurl <82838870+trurlurl@users.noreply.github.com>
* Fix faulty descriptions Documentation changes in the XSD for `FreeRecharging`, `Cage`, `RemoteControl`, `LocalControl` and `LockingMechanism` Refer to #999 for more details * Buggy SIRI import fix (#1001) The SIRI import is probably coming from a SIRI copy/paste since the NeTEx occupancy is following the SIRI one. The NaturalLanguageStringStructure is not NeTEx type, and is only used in this file, and doesn't follow NeTEx style/rules The SIRI import is crashing some generic NeTEx (and SIRI) import in some implementation (one of them being OpRa). The reason for this crash is difficult to analyse (and depending on the validation engine), but basically related to object redefinition. As a result this import was a useless and dangerous breaking change and has to be removed. * Edit changelog and readme (#997) * Update changelog * Remove redundancy with readme * Remove duplicates in the changelog details for v1.1.0 * Correct hierarchy of changelog for v1.0.9 and v1.0.8 * Delete change_log.md Remove redundant file * Fix link to CHANGELOG in README * Rename 'Change log' to 'Changelog' * Update README.md Co-authored-by: Thibaut Barrère <thibaut.barrere@gmail.com> * Update readme - typo (#1010) Update typo in the name of elements in the repo * Edit repo url after move + fix new org CI failures (#1015) 2 parts Pull Request Part 1: Edit the repo URL in - README.md - CHANGELOG.md - xsd/netex_part_1/part1_tacticalPlanning/netex_routingConstraint_version.xsd The change was to replace "NeTEx-CEN" with "TransmodelEcosystem" Part 2: Fix failing CI after moving the repo - Test CI after org migration (#1018) - Test: break indentation to trigger CI lint commit (#1018) - Try to fix CI (#1018): grant write permissions to workflow token - Lint and update documentation tables --------- Co-authored-by: Thibaut Barrère <thibaut.barrere@gmail.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> * Add some logic to prevent #982 from happening again (#1022) Ensure that - v2.1-wip branch is up to date from v2.0 before merging any PR - v3.0-wip branch is up to date from v2.1-wip before merging any PR --------- Co-authored-by: Stefan de Konink <stefan@konink.de> Co-authored-by: Christophe Duquesne <christophe.duquesne@aurigetech.com> Co-authored-by: Thibaut Barrère <thibaut.barrere@gmail.com>
| <xsd:documentation>Nature of use of stop, e.g. access, interchange only, or pass through. Default is Access.</xsd:documentation> | ||
| </xsd:annotation> | ||
| </xsd:element> | ||
| <xsd:group ref="QuayAssignmentGroup"/> |
There was a problem hiding this comment.
Did you place it in the middle to align it with Call?
There was a problem hiding this comment.
I tried. But different place would also be ok. We had in OJP some cases where we switched the order of some elements in service and this caused problems. So to do it as harmonised as possible seems a good idea to me.
There was a problem hiding this comment.
You understand that the way you are now doing it explicitly would break parsing and validation? So if it was deliberate to put them here, was this because in the other structures they are already at this point?
There was a problem hiding this comment.
What does it break? everything is optional in in.
There was a problem hiding this comment.
I do not see that the change would be incompatible in the sense that a pre-existing file would not validate any more. Maybe an existing importer could run into problems if it is not able to ignore unknown elements, e.g. it expects bookingElements to follow directly after AccessibilityAssessment. But this means we can add new optional elements only as the last element of the parent element.
duexw
left a comment
duexw
left a comment
There was a problem hiding this comment.
I am basically OK with the proposal. If we want to change from using Call to using PassingTimes, we need to put CheckConstraint somewhere. However, it would be nicer to have CheckConstraint in PassingTime as well. Why? Because Journeys with the same ServiceJourneyPattern may have different CheckConstraints. E.g. a congestion check constraint may only apply to peak time journeys. With the existing proposal, we would have to create extra ServiceJourneyPatterns in this case.
5 participants
replaces with #1019
but to right target andnow done in StopPointInJourneyPattern