The master branch is only available to OPC Foundation members ... about ua-nodeset HOT 14 CLOSED

@opcfoundation-org thank you for your answer and the comment. Also, changing the default branch to the latest release probably clarifies it a bit more.

Still, there are some open questions in the community, which are not yet completely clear, e.g., just look at the number of "thumbs up" and the referenced issues.

I have two more questions:

1. Nodesets which will be released in the future, will they always be immediately uploaded to this "open" repository?

2. Are open source projects allowed to use the work-in-progress "member nodesets" from https://github.com/OPCF-Members/UA-NodeSet for their development to fix bugs and implement features, as long as these nodesets are not made public?

from ua-nodeset.

The draft material in the private branch cannot be exposed in a public fork.
Private forks are fine.
Will update the readme to make that clear.

All draft material published in this repository as soon as the release version is posted to the OPC-F website.

It took some time to complete the transition, however, all released nodesets have just been pushed to the public repoand properly tagged.

from ua-nodeset.

@Pro the master branch contained draft and release candidate material. This material has always been restricted to members.

The v1.04 branch is now the default branch for this repository and the first branch people see when they navigate to the repo.

from ua-nodeset.

@opcfoundation-org So will be final future release versions of the nodeset accessible for the public?

from ua-nodeset.

BTW, let me add more general questions. My concern is if current standardization proposals covered by the OPC Unified Architecture suits of specifications are adequate to address the challenges of further development of the Internet of Things (IoT) and Industry 4.0 concept. These doubts may be expressed as a crucial question:

• Do we need Rel 2.0 of the OPC UA?

Nothing is done forever, hence the question will arise sooner or later. Based on my research on Object-Oriented Interned described in:

Chapter Object-Oriented Internet Reactive Interoperability (open access)

my opinion is that the question is not if but why rather. The answer must be a tradeoff between backward compatibility and further innovation deployment.

Notice that this repository contains only product/deliverables generated by a compiler. As a rule of thumb, all products of a compiler should be added to the .gitignore !? Following this rule, the whole repository should be ignored!! It makes sense because the source code is in a separate repository and you may use many existing tools the regenerate them. Thinking about the role of this repository contents, we may state that the files play a similar role as the NuGet packages - don't touch, use as is. Unfortunately, UANodeSet is in Part 6 as MANDATORY, although it doesn't affect directly in-band interoperability. I proposed to change the UANodeSet to be INFORMATIVE but it was rejected. My point is that this lack of consistency comes from lack of consistency between the Address Space (partially Part 3) and Information Model (partially Part 5) concepts. to get more check out my article

I am working on a consistent answer addressing the consecutive question of:

• Why we need Rel 2.0 of the OPC UA?

Your thought is welcome and will be very valuable for this work. Don't hesitate to share it with us.

from ua-nodeset.

@mpostal at this point in time the UA WG feels there will likely never be a need for a UA 2.0 because the specification has proven to be flexible enough to meet new requirements without the need for a rewrite.

from ua-nodeset.

@opcfoundation-org (Randy) Not sure if enigmatic UA-WG feeling is a good point in the discussion. Would you like to be so kind and point out a real proof of concept? In my post, you can find a description of a curious situation where all the rules governing the repository usage have been broken with the purpose to be compliant with the spec (Part 6) and needs of w few UA-WG members.
Anyway, I have got the "precise" answer. Keep it easy. You may close this issue as the followup of the UA-WG feeling. I don't care about this repository. The most important for me is https://github.com/OPCFoundation/UA-ModelCompiler, where the source (ModelDesign) files are located by accident, informally, published occasionally from time to time without any rules.

BTW, are there any signs that UA-WG is trustful in this respect? In contrast, my feeling (or just a dream) is that the Manufacturing Automation Protocol (MAP - https://en.wikipedia.org/wiki/Manufacturing_Automation_Protocol) supported by GM and Boeing is still alive - we may read the specification form cover to cover.

from ua-nodeset.

@mpostol a few points:

1. Most new companion specifications do not have ModelDesign files since the authors are using tools that do not use the format. So the design files in the ModelCompiler repo will always be incomplete. The repo will only be a reliable source for base UA specification ModelDesign files.

2. A similar pattern will be adopted for the ModelCompiler repo where the released ModelDesign files will be in the 1.04 branch which will be mirrored to the public repo. The Member-Only repo would be the only location for draft types.

The main barrier to getting 2) done is the tedious and error prone process explicitly removing draft types from the source ModelDesign files each time. The plan is to write a program to automate this.

3. The process for managing NodeSets has gone through of number of iterations because of the feedback from users. The hope is we now have a process that will work reliably for everyone who needs to use these files.

4. I am not sure why you expect proof of no UA 2.0 since we are speculating about the future which is uncertain by nature. My previous response should make it clear that people currently involved in the UA WG do not believe that UA 2.0 is necessary and there is no roadmap with UA 2.0 on it. Obviously, things change and the future is unknowable.

from ua-nodeset.

@opcfoundation-org thanks for your response. I understand your point. I did spend there a couple of years, so I know how it works. Let me only stress that I am using OPC UA 2.0 acronym only as a trademark of changes - it is not an end in itself. Therefore I am not speculating about the future but trying to discuss the drawbacks we are facing up today. How to call the development result is irrelevant. You mentioned one of the reasons for the changes. it is portability, reusability, compliance testing, development tracking, multi-vendor development, and last but not least the versioning of the models. My point is that the current methods are not adequate. For example, instead of tracking UANodeSet files in the repository, they shall be digitally signed against the nonrepudiation rules. Can you provide a simple rule we will apply to know if modification is relevant or irrelevant? Unfortunately, the compiler can generate hundreds of equivalent (leading to instantiate the same Address Space) but completely different text files. The only requirement is compliance with the schema. In this context, the tracing functionality is useless, so the same is for versioning.

Anyway, thanks for your feedback. I will consider writing about it in my next manuscript about new challenges addressing IoT and Industry 4.0 requirements.

from ua-nodeset.

@mpostol there is no need for digital signing of NodeSets that are part of specifications which are not digitally signed. It adds complexity for no benefit.

The need for digital signatures comes in when you look at creating documents that represent the offline configuration of a server rather than a document that simply represents nodes in the address space. While the nodes in the address space are part of the offline configuration they are not all of it. For that reason, the problem is better solved with a container document that combines multiple pieces of information, including a NodeSet, and a mechanism to attach signatures.

A container document also makes it easier to track and attribute changes to the content.

from ua-nodeset.

@opcfoundation-org Let me stress that files in the repository are XML files, but I cannot find any specification document here. How to prove that these files are part of something else if they are maintained separately? The specification documents are to be read by people so digital signature has no value at all - you are right. The XML files are intended to be read by machines, and in this case, the digital signature is used for verification of authenticity and consistency- it is not only value it is also a security-based requirement today. As you know, we have discussed this topic many times, the XML files may contain errors sometimes very serious. I hope we must not read your comment as the proposal to manually diff the paper and electronic versions of the XML files.

You have mentioned the next very important topis for further discussion, namely the purpose of the UANodeSet files. Do you mean they are intended to instantiate Address Space managed by a UA Server only? What about reusing them by the community to create derived models? What about reusing them to create dedicated, selected model aware clients? What about using them to create the semantic context of the publisher/subscriber interoperability? What about using them to produce plug and produce equipment, e.g. robots? There are hundreds of scenarios where Information Models may be useful especially in the context of IoT an I4.0.

Still, I am pretty sure that we need OPC UA 2.0 with the purpose to improve understanding of the two autonomous concepts: Address Space as a description of the nodes collection instance (run-time - the power supply is required to keep them alive), and Information Model as a formal description of parts interoperability (design-time - it may be curved in stones). The coupler for them is for example your ModelCompiler. We are not very far from existing solutions.

BTW, I will appreciate removing your face mask. This way it is not possible to be infected by any COVID for sure, so covering your identity using the organization account is not necessary :).

from ua-nodeset.

@mpostol We don't need UA 2.0 to improve the NodeSet format.

Please submit feature requests to Mantis which will ensure they are discussed by the WG and that you get a formal answer.
https://apps.opcfoundation.org/mantis/

from ua-nodeset.

@opcfoundation-org I don't need the WG formal answer. I have joined this discussion because @Pro started a very interesting topic for my research. There are many reasons. First is that the answer always looks very similar. Recently I have got: Agreed to no-fix in virtual F2F.

Second, look at the time table:

Date Submitted:             2018-04-22 17:15 EDT
Last Modified:              2020-06-17 11:51 EDT

Date Submitted means I reported, Last Modified means that I receive a formal answer (2+ years !!!).

@opcfoundation-org I will really appreciate any suggestion that will support my motivation in this respect.

Fortunately, today the OPC UA is only an entry in my list of references - nothing more. I believe that in the future the role of the de-facto standards driven by the community will grow. For example, you are welcome to join the open-access project
OPC UA Makes Machine-Centric Global Village Possible – Call for Sponsors
Check out the following section to get more How to be involved. There is a place for founders and developers.

@Pro sorry for overtaking your issue. Answering your question, my point is that you are right, the open-access (including but not limited to open-source) is crucial for further development of community common intellectual properties, but not in this case. In this case, we have much more serious problems that we must face up as the community. Fortunately, we have DOI to make a snapshot of the current development of documents, we have GitHub to make a snapshot of the current development of any textbase deliverables. We have ORCID to contribute as individuals and avoid sheltering by nicknames. There is no need to wait for 2 yeara to get information that the contribution is just neglected.

from ua-nodeset.

@Pro sorry for overtaking your issue. Answering your question, my point is that you are right, the open-access (including but not limited to open-source) is crucial for further development of community common intellectual properties, but not in this case. In this case, we have much more serious problems that we must face up as the community.

Hmm, yeah it's not so well taken in the open source community to overtake an issue with a different topic. The main idea behind keeping issues separate, is to quickly inform an interested reader on the solution and the most important points.
I understand some points you made, but please create a new issue if you have specific questions which are not directly related to the original issue I posted (master branch empty).
Now this issue is very overloaded and if someone is interested in why there is no more master branch, he/she has to read through all the other texts as well.

I'm closing this issue for now, as it was answered by the OPCF. Feel free to reopen a new issue and reference this one if necessary.

from ua-nodeset.