Closed
Conversation
* Removed comment about which editor made the change * Removed comment about which editor was used
* Added Spotless tool to verify and correct xsd/xml file formatting * Attempt at making Travis validate * Add more JVM memory, appears to speed up the formatting process * Only require reformatting of files that have changed since 'master' branch * Improved documentation * More docs on formatting * Fix command line option * Replaced shall with must for character encoding * Initial reformatting using Spotless - rules from Eclipse WTP project located in eclipsecodestyle/xml.prefs * More reformatting after rebasing * Updated copyright header year (just to trigger build) * Set travis timeout to 6 hours. Must be reverted after first build * Make jar plugin include all xsd files * Bump spotless to latest version * Run maven with debug trace * Attempt at getting travis to run * Disabled formatting checks in travis temporarily
… ConditionSummaryStructure
ConditionSummaryChargingGroup not referenced from ConditionSummaryStructure
…ationGroup Fix annotation errors and align with definitions in NeTEx pt 3
Contributor
|
Just as a side note: I fully agree that "deembeding" is sometimes useful, and that's one of the reasons why France choose the GeneralFrame as a base (and specialised it in the profile) since this already allows deembding (for example, with Quays, see the Le Corbusier - SQYBUS-NeTEx-Profil Arret - External Quays.xml file in the NeTEx SXD example hierarchy). |
Contributor
|
yes, please. |
Contributor
|
@skinkie what do we do with this PR? |
Contributor
Author
|
@nick-knowles doesn't like it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From the experiences I have had over the past years with the actual use of the NeTEx datamodel, I have come to the realisation that one of the most problematic NeTEx points are generic object embeddings. An example of a generic embedding is a Quay which can currently only be placed under a StopPlace. This has the consequence that a StopPlace must always be defined in order to define a Quay.
Does NeTEx have a solution for it? Yes, one could use a GeneralFrame, which allows to embed any object in any order, but this also loses all the semantic context which are available between parent-child relations and frames.
What I would propose:
Does this resolve everything? Certainly not. NoticeAssignment is a great example that can be applied to any object identifier, and would still require "magic" to correctly link. The other consequence is making inheritance and inference vague for many to one relationships. It is clear that a StopPlace/quays/Quay can infer content from its parent, but would the same go for StopPlace/quays/QuayRef?