[JohanEntur]

Once more I am clicking buttons on behalf of Entur.
This was created ages ago by people in Entur but it was never merged up to CEN.

[skinkie]

Is "future use" something that is in scope or out scope, because for example a ValidityBetween should have been provided.

[JohanEntur]

where are you quoting from?

[skinkie]

where are you quoting from?

The ideas in my mind after reviewing this addition.

[JohanEntur]

aha well. yes and no. our customers keep requesting "send file import later"-features so that they are able to sync their real-time systems (which have a much slower turnover than our import), but.... I dont know. As you say, it could be a validty date too but it requires so much from the various system to a) know about the value b) know what it means c) implement logic for it. I dont think the world is ready for such advanced syncronized data activation.

But, maybe this is not the usecase you were thinking of.

[skinkie]

My use case is basically, there will be renovated station in the future. But obviously the planned state is available. I think people are interested in knowing what the station looks like in the future.

[JohanEntur]

so its a stopplace with versions

[trurlurl]

Suggestions for a more precise name: publicationSharingPolicy, publicationVisibility

[vpaturet]

We would prefer to stick to "publication" for concision. This does not seem to collide or cause ambiguity with other existing attributes.

[vpaturet]

@skinkie We are refreshing this PR, could you change the target branch from v2.0 to v2.1-wip?
(This requires write access, I cannot do it)

[vpaturet]

My use case is basically, there will be renovated station in the future. But obviously the planned state is available. I think people are interested in knowing what the station looks like in the future.

As Johan said, this feature is orthogonal to validity period or future state. It is about the audience (is this entity intended to be communicated to the public or is it internal?)

[skinkie]

@vpaturet @JohanEntur I don't have the permissions to change your target branch.

[TuThoThai]

@vpaturet @JohanEntur I don't have the permissions to change your target branch.

@skinkie, @vpaturet, @JohanEntur, since the PR is based on a fork of the repo in another organisation (Entur), I cannot change the target either.
Only solution is to redo the PR using a feature branch in this repo, based on branch v2.1-wip

I will look at it later for the redo.

[skinkie]

@vpaturet @JohanEntur I don't have the permissions to change your target branch.

@skinkie, @vpaturet, @JohanEntur, since the PR is based on a fork of the repo in another organisation (Entur), I cannot change the target either. Only solution is to redo the PR using a feature branch in this repo, based on branch v2.1-wip

I will look at it later for the redo.

Just let Johan do the work, single click.

[vpaturet]

@skinkie @TuThoThai Thanks, we managed to change the target branch and update the PR.

[BredeD]

Can we please get this into 2.0 version or a new 2.0.1. This is blocking our implementation of 2.0 at Entur and the Norwegian NeTEx Ecosystem of NeTEx.

Else, when is 2.1 planned to be released?

We have made significant progress and are rolling out 2.0 support for both import and output, one team at Entur are converting to 2.0. This is good news. We need this to support all data sources on NeTEx 2.0.

[skinkie]

@BredeD I think this is a very bad idea. What you propose basically adds a potential attribute to every object, that some how needs to be enforced, also when embedded in other objects. I wonder if this should be at entity level or at PublicationDelivery / Frame etc. If you indeed see good use for a mixture of public and confidential information without mentioning anywhere at the top of the file that the file contains confidential elements, that sounds like a disaster waiting to happen.

[ue71603]

@BredeD I think this should be only on PublicationDelivery. Different restrictions call for different deliveries in my view. I think there is also less pushback from Stefan (and myself, for the introduction) and also, something isn't NeTEx 2.0, when it is not there. NeTEx 2.1 should be ready (also for my needs by end of year, if we manage. You can see, what needs to be done.

I would also like to have 2.1 by the end of the year. but we have a long way to go: https://github.com/TransmodelEcosystem/NeTEx/issues?q=is%3Aissue+state%3Aopen+milestone%3Anetex_2.1 (with 55 open issues/PR)

and 6 for NeTEx 2.0: https://github.com/TransmodelEcosystem/NeTEx/issues?q=state%3Aopen+milestone%3Anetex_2.0

That's why we intend to start merging faster. If you have a reviewer from ENTUR ready that would help.

[BredeD]

Thanks, @skinkie @ue71603.
My gut feeling was that this issue was clear and just needed the merge clicks.
We'll look into how we can help with the reviews and we will come back to this issue.

[skinkie]

@BredeD if you are faithfully want to export a database with confidential and non-confidential information, like a general frame with everything in it, and it is a mixture in the internal database as well. Feel free to pursue what has been proposed. My feeling is this not your intention and you are looking for this at publication level.