link between program/event/report and ven/resource

[whistlingdogg]

Hi, Thanks for creating such a great project. I'm looking into openADR3.0 and came across this project. Whilst the documentation for openADR3.0 seems quite extensive, it appears to no describe certain key relationships and/or ideas. This could either be due to "in progress" or it is on purpose as to allow flexibility.

I'm comfortable with the idea of program,event and report and also the way that vens are described and their associated resources. What I do not see is any link between these 2 sets of entities. I don't see any examples in the openADR docs that even use ven/resource.

I see from your implementation that you have created an additional reltionship between program and ven (ven_program) by joining an optional target (type VEN_NAME) to the ven_name of the ven. Is this to show that only that ven can see programs (and therefore events & reports)? This seems like a core concept and I'm surprised it is not called out in the documentation (there is a single reference VEN_NAME targetType in the docs). As I mentioned, this could be to allow flexibility in how a ven is related to programs but it is left quite vague

[pohlm01]

Thanks a lot for your question. I agree with you that the OpenADR specification is unclear in this regard. Unfortunately, I'm not the author of the specification and, therefore, had quite some problems interpreting such details as well. Now, I'm in contact with the alliance and try to clarify such details in the upcoming OpenADR 3.1 release, but improvements are incremental, i.e., not everything will be fixed in the next release. As the specification process is very long-winded, we had to assume a few things that are not clearly specified to create this implementation, even if they are possibly not what is intended.

Your specific question is one such point. You are correct that the specification does not specify any relation between a program and ven. Because we do not agree with the specification's lax access control, we had to find a way to allow a more fine-grained access control while simultaneously being as close to the spec as possible. Specifically, we use the VEN_NAME target in a program to limit the visibility to specific VENs. We assume this can be helpful for non-public programs that are specific to one or a few VENs. This is the feature you observed in the code. If the VEN_NAME target is not set, any VEN can access the program.

Unfortunately, this behavior is not yet sufficiently documented. We hope that we can spend more time on that project soon again and, as part of that, also improve the documentation, which can obviously never be good enough.

I hope this answers your question. If anything is still unclear, I'm happy to hear that.

[whistlingdogg]

Thanks for your response. It's interesting that you mention 3.1 release. Are there any published timelines around this? I'd be really interested to understand where they are taking this. I have a piece of work to complete that's roughly 6 months that is supposed to be based on openADR 3.0 but would not like to paint myself into a corner by going down the wrong route.

[pohlm01]

I'm not aware of any publicly shared timeline, but I don't think I told you a secret letting you know that the end of March is targeted. I assume they did not share this date yet to not commit to it yet. Therefore, please take this information with salt, as this timeline can still change.