GitLab

• Allgemeines

• Attribute mit Kardinalität >1 sollten Plural-Namen haben (Bsp.: Klasse Submodel: Attribut submodelElements – im JSON-Schema wurde das bereits umgesetzt – und als Beschreibung "List of zero or more submodel elements")
• Sind Listen bei Kardinalität ..* unordered oder ordered?
• Warum AASd-001 bei Constraint anstatt AAS-001
• Die Schemata sollten online und unter einer freien Lizenz zur Verfügung gestellt werden.
• In den Beispielen sollte eine Domain der Plattform I4.0 oder die frei nutzbare Domain example.com verwendet werden statt der fremden Domain "customer.com", die der Customer Communications Group Inc. gehört (z.B. in http://customer.com/assets/KHBVZJSQKIY).
• HasDataSpecification führt dazu, dass das Meta-Modell dynamisch erweitert werden kann. Dies lässt sich in einem statisch typisierten SDK nicht allgemein umsetzen. Es handelt sich damit quasi immer um eine Implementierungs-spezfische Erweiterung. Es ist also überflüssig dies im Metamodell zu beschreiben. Stattdessen sollten Objekt-Attribute, die für eine Interoperabilität benötigt werden, im Metamodell als Klassen hinzugefügt werden (z.B. eine IEC61360ConceptDescription); alle anderen Erweiterungen sind Implementierungs-Details.

JSON-Schema

• JSON-Schema hat inkorrekte JSON-Syntax: ',' an manchen Stellen zu viel
• JSON-Schema erwartet eine semanticId vom Typ Reference bei allen HasSemantics-Objekten, obwohl die semanticId laut Metamodell optional ist.
• JSON-Schema erwartet ein verpflichtendes value bei Property, Qualifier, Blob, usw., obwohl dieses laut Metamodell optional ist.
• Die Definition von modelType stimmt im JSON-Schema nicht mit der im Dokument beschriebenen JSON-Syntax überein: Laut Schema muss es ein JSON-Objekt {"name": "NameOfTheAASClass"} sein, laut Kapitel 5 im Dokument nur ein String mit dem Klassennamen.
• Blob: Ein JSON-String kann keine beliebigen Binärdaten, sondern nur Unicode-Zeichen serialisieren. Wir schlagen daher base64-Encoding des value vor.
• Blob und File value ist im Meta-Modell optional und im Schema verpflichtend
• Im Beispiel-JSON-Dokument: "www.vdi2770.com/blatt1/Entwurf/Okt18/cd/StoredDocumentRepresentation/DigitalFile" ist keine valide IRI, da das Schema fehlt. Vgl. RFC3986 Abschnitt 3
• Der Type des Attributs MultiLanguageProperty.value ist LangStringSet, das JSON Schema erlaubt jedoch nur einen LangString.
• Das Enum der zulässigen Werte für valueType ist unnötiger Weise mehrfach im JSON Schema definiert, statt zentral als Typ definiert zu werden.

Abstrakte und allgemeine Typen

• LangString: Wie sollen die Annotationen funktionieren? Sollte ein Mapping mit einem String nach ISO 639-1 und ISO 3166-1 und einem String sein.

Reference & Referable

• Referable.parent
  • Constraint AASd-004 ist in der Umsetzung nicht sinnvoll (z.B. Factory-Funktionen, die Objekt zunächst ohne Parent anlegen).
  • Für die Implementierung ist es sinnvoll, wenn ein Implementierungs-spezifischer Verweis auf der parent (d.h. ein Pointer) auf das Parent-Objekt dort gespeichert wird, statt eines Reference-Objects.
  • Eigentlich ist ja ohnehin ein Implementierungsdetail. Warum wird das überhaupt im Metamodell festgelegt?
• Namespace als abstrakte Klasse im Metamodell einführen und Namensauflösung von References erklären* Kardinalität von Referable.idShort sollte 0..1 sein, um das Constraint AASd-001 sinnvoll umzusetzen.
• Ist es Absicht, dass Qualifier nicht Referable sind?
• Was sind "Letters", die in der Referable.idShort vorkommen dürfen? Englisches Alphabet? Druckbare ASCII-Zeichen? Druckbare Unicode-Zeichen?
• Referable.idShort sollte entweder nur Kleinbuchstaben (welche? s.o.) enthalten dürfen oder case-sensitive betrachtet werden. Case-insensitive Stringvergleiche sind echt hässlich (da zusätzliche Transformation nötig), insbesondere, wenn man Unicode erlaubt (da dann nicht mehr eindeutig definiert).
• Es sollte einen optionalen Displayname ohne Constraints für alle Elemente, zusätzlich zu den IDs geben
• Vorschlag für Redesign der References:
  • Drei verschiedene Referenz-Typen:
    • AASIdReference (Enthält nur Typ und einen Identifier; wird für Einbindung von Teilmodellen in VWS etc. genutzt)
    • AASReference (Enthält Typ, einen Identifier und einen Pfad von idShorts; wird benötigt für ReferenceElement etc.)
    • ExternalReference (Enthält nur eine URI, ggf. mit Fragment; Keine integrierte Dereferenzierung)
  • Key und KeyType wegwerfen
  • Vererbung von Referable und Identifiable überdenken: Identifiables sollen per PathReference referenzierbar sein, brauchen jedoch keine idShort oder Parent
  • Grund: Key.type und Key.local werden nicht wirklich gebraucht, oder? Stattdessen sollte die Referenz einen Typ haben. Die verschiedenen o.g. Referenzentypen müssen unterschiedlich aufgelöst werden und haben eine unterschiedliche Semantik (Einbindung von entfernten/geteilten Elementen der VWS / Referenz auf ein anderswo lokalisiertes VWS-Objekt / Referenz auf einen externen Datensatz).
• Verwaltungsschalen enthalten aktuell nur Referenzen (ohne IdShort etc.) auf ihre Teilmodelle. Die Teilmodelle selbst sind somit nicht in der Verwaltungsschale enthalten. Das widerspricht jedoch der Art und Weise wie (z.B. im aktuellen Entwurf der REST-API) darauf zugegriffen wird. Insbesondere: Wie soll der Zugriff per idShort auf ein Teilmodell hier aufgelöst werden? Das Metamodell sieht dazu nichts vor.

Security

• Security Part macht so keinen Sinn. Besser rausnehmen, als unsinnige Sachen drinnen lassen. Ansonsten:
  • Security.requiredCertificateExtension hat unsinnigen Typ (Reference)

SubmodelElements

• Sollte Property.value nicht verpflichtend sein? Ebenso für ähnliche Submodel-Elements.
• Warum muss Range mindestens eine Grenze haben (Constraint AASd-013) – im Gegensatz zu Property.value?
• Wozu ist allowDublicated bei SubmodelElementCollection?