|
|
* ## Allgemeines
|
|
|
* [X] Bitte die UML-Syntax fixen (Assoziations-Pfeile)
|
|
|
* [X] Bitte Vererbungshierarchien in UML-Diagramme von oben nach unten gestalten
|
|
|
* [ ] Attribute mit Kardinalität >1 sollten Plural-Namen haben (Bsp.: Klasse Submodel: Attribut submodelElement**s** – im JSON-Schema wurde das bereits umgesetzt – und als Beschreibung "List of zero or more submodel elements")
|
|
|
* [x] Attribute mit Kardinalität >1 sollten Plural-Namen haben (Bsp.: Klasse Submodel: Attribut submodelElement**s** – im JSON-Schema wurde das bereits umgesetzt – und als Beschreibung "List of zero or more submodel elements")
|
|
|
* [X] Sind Listen bei Kardinalität ..* unordered oder ordered?
|
|
|
* [X] 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`).
|
|
|
* [x] Die Schemata sollten online und unter einer freien Lizenz zur Verfügung gestellt werden.
|
|
|
* [x] 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`).
|
|
|
|
|
|
## 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`.
|
|
|
* [x] JSON-Schema hat inkorrekte JSON-Syntax: ',' an manchen Stellen zu viel
|
|
|
* [x] JSON-Schema erwartet eine `semanticId` vom Typ `Reference` bei allen `HasSemantics`-Objekten, obwohl die semanticId laut Metamodell optional ist.
|
|
|
* [x] JSON-Schema erwartet ein verpflichtendes `value` bei Property, Qualifier, Blob, usw., obwohl dieses laut Metamodell optional ist.
|
|
|
* [x] 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.
|
|
|
* [x] `Blob`: Ein JSON-String kann keine beliebigen Binärdaten, sondern nur Unicode-Zeichen serialisieren. Wir schlagen daher base64-Encoding des `value` vor.
|
|
|
* [x] Blob und File value ist im Meta-Modell optional und im Schema verpflichtend
|
|
|
* [x] 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
|
|
|
* [x] 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
|
... | ... | @@ -26,20 +24,20 @@ |
|
|
* [X] Constraint AASd-004 ist in der Umsetzung nicht sinnvoll (z.B. Factory-Funktionen, die Objekt zunächst ohne Parent anlegen).
|
|
|
* [X] 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.
|
|
|
* [X] Eigentlich ist ja ohnehin ein Implementierungsdetail. Warum wird das überhaupt im Metamodell festgelegt?
|
|
|
* [X] Namespace als abstrakte Klasse im Metamodell einführen und Namensauflösung von `Reference`s erklären* Kardinalität von `Referable.idShort` sollte `0..1` sein, um das Constraint AASd-001 sinnvoll umzusetzen.
|
|
|
* [ ] Namespace als abstrakte Klasse im Metamodell einführen und Namensauflösung von `Reference`s erklären* Kardinalität von `Referable.idShort` sollte `0..1` sein, um das Constraint AASd-001 sinnvoll umzusetzen.
|
|
|
* [X] Ist es Absicht, dass `Qualifier` nicht `Referable` sind?
|
|
|
* [X] Was sind "Letters", die in der `Referable.idShort` vorkommen dürfen? Englisches Alphabet? Druckbare ASCII-Zeichen? Druckbare Unicode-Zeichen?
|
|
|
* [X] `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).
|
|
|
* [X] Es sollte einen optionalen Displayname ohne Constraints für alle Elemente, zusätzlich zu den IDs geben
|
|
|
* [X] Vorschlag für Redesign der References:
|
|
|
* [X] Drei verschiedene Referenz-Typen:
|
|
|
* [ ] 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.)
|
|
|
* [X] ExternalReference (Enthält nur eine URI, ggf. mit Fragment; Keine integrierte Dereferenzierung)
|
|
|
* [X] Key und KeyType wegwerfen
|
|
|
* [X] Vererbung von Referable und Identifiable überdenken: Identifiables sollen per PathReference referenzierbar sein, brauchen jedoch keine idShort oder Parent
|
|
|
* [X] 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.
|
|
|
* [ ] 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).
|
|
|
* [x] 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
|
|
|
* [X] Security Part macht so keinen Sinn. Besser rausnehmen, als unsinnige Sachen drinnen lassen. Ansonsten:
|
... | ... | @@ -48,9 +46,4 @@ |
|
|
## SubmodelElements
|
|
|
* [X] Sollte `Property.value` nicht verpflichtend sein? Ebenso für ähnliche Submodel-Elements.
|
|
|
* [X] Warum muss Range mindestens eine Grenze haben (Constraint AASd-013) – im Gegensatz zu `Property.value`?
|
|
|
* [X] Auf was für eine Art von Daten/Object verweist `Property.valueId`?
|
|
|
* [X] Wozu ist allowDublicated bei SubmodelElementCollection? |
|
|
* [ ] Wenn OperationVariable kind = Template hat, wofür kann man das dann in der Instanz nutzen? Müsste dann nicht auch Operation kind = Template haben?
|
|
|
* [ ] Verwaltungsschalen enthalten aktuell
|
|
|
|
|
|
|