Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resolve #432 remove AASd-120: idShort also allowed for elements #458

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
104 changes: 38 additions & 66 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,51 +1,29 @@
# Contributing

The [Specification of the Asset Administration Shell - Part 1] is an official publication of the [IDTA] work stream "Specification of the Asset Administration Shell".
The API definitions in this repository must be particularly compliant with this specification.
To ensure a faster adoption and improvement of AAS API, we invite the community to contribute with reviews, reporting issues, and fixing them.
Do you want to contribute? Great! But before you do it, please follow the defined procedure for the contribution in this repository.

[Specification of the Asset Administration Shell - Part 1]: https://industrialdigitaltwin.org/en/content-hub/


## Prerequisites

**Please note** that by submitting an Issue or a Pull Request (PR), you aggree that the created content falls under a Developer Certificate of Origin ([DCO]), by which you declare that you have the legal right to contribute the content under the stated license and that the [IDTA] and the maintainers of this repository are allowed to use your contribution for publications, e.g., [Specification of the Asset Administration Shell - Part 1]. In certain cases, an additional signing of a Contributor License Agreement (CLA) can be required. It is up to the maintainers of this repository to decide whether an individual contribution needs also a signed CLA. In case the contributor does not sign it in an appropriate time span after being notified, the contribution cannot be used further and in particular can not appear in any release.

[DCO]: https://developercertificate.org


## Raising Issues

[Github Issues](https://github.com/admin-shell-io/aas-specs/issues) are the preferred way to inform the community about bugs, shortcomings, feature requests and so on.


**Use a template**. Several issue templates are available to better structure the process. Depending on your issue, submit a review finding, a bug report, or a request for a new feature. Only if none of these fits, [open a new blank issue](https://github.com/admin-shell-io/aas-specs/issues/new). Due to legal reasons, click also the checkmark stating that you have already signed the [DCO] (see [Section Prerequisites](#prerequisites)).
A maintainer will then assign additional labels, milestones, and individual other contributers if possible.
The specification of [Asset Administration Shell - Part 1] is an official publication of the joint working group "Asset Administration Shell" of the [Platform Industrie 4.0] and [IDTA].
The specification and schema definition, including application examples in the aas-spec repository must be particularly compliant with this.
However, we invite the community to review, report and fix the specification and schema definitions, including application examples.
Therefore, we demand a defined procedure for the contribution in this repository.

[Asset Administration Shell - Part 1]: https://www.plattform-i40.de/PI40/Redaktion/EN/Standardartikel/specification-administrationshell.html

## Before the Pull Requests

If you are contributing for the first time, please inform yourself about the [LICENSE](./LICENSE.txt) used for this repository. Also, you will be asked to sign a [DCO] if not done already (see [Section Prerequisites](#prerequisites)). Different to issues, Pull Requests are checked automatically through the [CLA Assistant](https://cla-assistant.io).


**Create Feature branches**.
We develop using feature branches, see [this section of the Git book].
We develop using the feature branches, see [this section of the Git book].

[this section of the Git book]: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows.
[this section of the Git book]: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

If you are a member of the IDTA workstream team, [create a feature branch] directly within the repository.
If you are a member of the development team, [create a feature branch] directly within the repository.

[create a feature branch]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository

Otherwise, if you are a non-member contributor, fork the repository and create the feature branch in your forked repository. See [this Github tutorial] for more guidance.

[this Github tutorial]: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork



**Branch Prefix**.
Please prefix the branch with your Github user name (*e.g.,* `my-user/Add-some-feature`).
Please prefix the branch with your Github user name (*e.g.,* `mristin/Add-some-feature`).

## Recommendation for Commit Messages

Expand All @@ -60,71 +38,65 @@ The commit messages follow the guidelines from https://chris.beams.io/posts/git-

## Create Pull Request
After all changes have been committed to your feature branch, a [pull request] (PR) has to be created.
Every PR must be linked to an issue for tracking.
Every PR should be linked to an issue for tracking.
See [this Github tutorial] for more guidance.

[pull request]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

[link PR to issue]: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

The discussion on the issue's content happends in the issue and not the PR. The discussion in the PR should focus on the reviewer's remarks.

## Pre-Merge Checks
**Continuous Integration.**
Github will run the continuous integration (CI) automatically through Github actions to verify that the submitted changes are valid.
Every pull request automatically runs the continuous integration with every update.

The continuous integration must be **successfully completed** with `All checks have passed` before proceeding with the approval process.

### Schema Validation
We use the sample programs from [schema-validation] repository in the continuous integration to validate the schemas against the [JSON], [XML] and [RDF] examples from the aas-spec repository.
It is possible, but not necessary to check the schema-validation without creating the pull request.

[schema-validation]: https://github.com/admin-shell-io/schema-validation
[JSON]: /schemas/json/examples
[XML]: /schemas/xml/examples
[RDF]: /schemas/rdf/examples

First you need to install the schema-validation, invoke:

```
schemas\InstallSchemaValidation.ps1
```

Afterwards you run the script to validate the example data against the schemas by calling:

```
schemas\Validate.ps1
```

### Check Commit and Pull Request Messages
In accordance with Section "Recommendation for Commit Messages" the continuous integration checks the previously defined conditions.
For the present development, however, this is not enforced.

## Approval Process
All changes must be **reviewed** and **approved** by members of the IDTA workstream "Specification of the Asset Administration Shell".
All changes must be **reviewed** and **approved**.

Minor changes (simple failures, typos, *etc.*) and additional content (more examples, etc.) can be accepted straight away after a brief review by at least one responsible reviewers.
Minor changes (simple failures, typos, *etc.*) and additional content (more examples, etc.) can be accepted straight away after a brief review by the responsible reviewers.

Major changes must first be presented and approved in the [IDTA] workstream "AAS in Detail". If the creator of a PR is not a member of the workstream, a dedicated assignee will present it.
Major changes must first be reviewed and approved by the joint working group "Asset Administration Shell" of the [Platform Industrie 4.0] and [IDTA].

[Platform Industrie 4.0]: http://www.plattform-i40.de
[IDTA]: https://industrialdigitaltwin.org/


## Merge into `main` Branch
## Merge into Master Branch

After the approval, the pull request can be merged into the repository. This is done by one of the maintainers.
Bugfixes might be collected together first and then be merged through one indivdual commit. Similarly, new features are first collected in defined minor/major release branches, and merged into the `main` at the time when the corresponding version of the specification is published.

*Note:* Changes into external resources, e.g. Swaggerhub, are done by the members of the IDTA workstream immediatly after the indivdual PRs have been merged. The leading source is always the content of this repository.
After the approval the pull request can be merged into the repository. This is done by one of the maintainers.


## Post-Merge Cleanup
**Congratulation.**
You successfully contributed to the aas-spec-api repository.
You successfully contributed to the aas-spec repository.

If you are a member of the workstream team, please delete the feature branch you directly created within the aas-specs repository.
If you are a member of the development team, please delete the feature branch you directly created within the aas-specs repository.

Otherwise, if you are not part of the team and you forked the repository, feel free to delete your fork.


## License Headers & Licensing

By default, all files contributed require headers - this will ensure the license and copyright clearing at the end. Only if inline comments are not possible, e.g., for JSON files, the copyright declaration can be omitted.

Also, all contributions must have the same license as the source.

The header should follow the following template:

```
////
Copyright (c) 2023 Industrial Digital Twin Association

This work is licensed under a [Creative Commons Attribution 4.0 International License](
https://creativecommons.org/licenses/by/4.0/).

SPDX-License-Identifier: CC-BY-4.0

////
```

Binary file removed documentation - Copy.zip
Binary file not shown.
Binary file not shown.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
8 changes: 4 additions & 4 deletions documentation/IDTA-01001/modules/ROOT/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
Copyright (c) 2023 Industrial Digital Twin Association

This work is licensed under a [Creative Commons Attribution 4.0 International License](
https://creativecommons.org/licenses/by/4.0/).
https://creativecommons.org/licenses/by/4.0/).

SPDX-License-Identifier: CC-BY-4.0

Expand Down Expand Up @@ -36,7 +36,7 @@ SPDX-License-Identifier: CC-BY-4.0
* xref:general.adoc[General]


* xref:spec-metamodel/index.adoc[Specification (normative)]
* xref:spec-metamodel/nav-spec.adoc[Specification (normative)]

** xref:spec-metamodel/overview.adoc[Overview]

Expand Down Expand Up @@ -64,9 +64,9 @@ SPDX-License-Identifier: CC-BY-4.0

* xref:grammar-semantic-ids-metamodel.adoc[Grammar Semantic IDs for Metamodel]

* xref:mappings/mappings.adoc[Mappings (normative)]
* xref:mappings.adoc[Mappings (normative)]

* xref:summary-and-outlook.adoc[Summary and Outlook]
* xref:summary-and-outlook.adoc[Summy and Outlook]

* xref:./annex/nav_annex.adoc[Annex]

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -14,8 +14,7 @@ Plattform Industrie 4.0; Anna Salari, Publik. Agentur für Kommunikation GmbH, d
[appendix]
= Backus-Naur-Form

The Backus-Naur form (BNF) – a meta-syntax notation for context-free grammars – is used to define grammars.
For more information see https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form[Wikipedia].
The Backus-Naur form (BNF) – a meta-syntax notation for context-free grammars – is used to define grammars. For more information see https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form[Wikipedia].

A BNF specification is a set of derivation rules, written as

Expand Down Expand Up @@ -46,7 +45,7 @@ where:

<e-mail-Addresses> ::= {<e-mail-Address>}*

<e-mail-Address> ::= <local-part> "@" <domain>
<e-mail-Addresse> ::= <local-part> "@" <domain>

<name> ::= characters

Expand All @@ -64,6 +63,8 @@ Hugo Me e-mail addresses: [email protected]
Hugo e-mail addresses: [email protected]
....



Invalid contact addresses:

[example]
Expand Down
Loading
Loading