In meinem Anwendungsfall wird ein externer Katalog zu einem Modell geladen und zur Klassierung von Datenobjekten verwendet.
Im externen Katalog kommt TID="1001" vor. In meinen Datenobjekten gibt es ebenfalls ein Objekt mit TID="1001".
Der ilivalidator gibt mir dazu eine Fehlermeldung aus. Sollte das aber nicht „gefressen“ werden? Die korrekte Referenzierung sollte doch über die Modelldefinitionen und die Namensqualifizierungen sichergestellt sein?
M.E. kann es nie ausgeschlossen werden, dass in einem externen, eingebundenen Datensatz eine gleiche TID vorkommt, wie in meinen Transferdaten… (?)
Oder verstehe ich hier etwas konzeptionell grundfalsch?
Meine Recherche dazu im Referenzhandbuch hat folgendes ergeben:
Es ist grundsätzlich möglich, dass ein Transfer Behälter aus verschiedenen Modellen enthält.
(RefHB ILI24, Kap. 4.2.4)
und
In der Transferart FULL müssen alle %Tid% innerhalb des gesamten Transfers eindeutig sein. In der Transferart INITIAL oder UPDATE müssen die %Tid% global eindeutige OID’s sein.
(Kap. 4.3.7)
Zudem: Wird innerhalb der Transferdatei keine Transferart angegeben, so wird FULL angenommen (Kap. 4.3.7). FULL ist meines Wissens der Normalfall, deshalb gehe ich in deiner Fragestellung ebenfalls davon aus.
Daraus ziehe ich den Schluss, dass die Fehlermeldung gerechtfertigt ist, da RefHB-konform („alle TID im Transfer müssen eindeutig sein“). Wie weit eine Deklaration der Transferart als INITIAL etwas bringen würde, erschliesst sich mir aus obigem Zitat nicht.
Danke für die Replik! Ja, mit OID wäre das alles obsolet.
Aber: die externen Kataloge sind ja nicht Teil des Transfers! Es werden nur Referenzen darauf erfasst, und bei der vollständigen Datenvalidierung muss deshalb mittels ilidata: ... angegeben werden, in welchem Dataset die Kataloge zu finden sind…
Doch, aus meiner Sicht sind sie Teil des Transfers. Der Transfer ist einfach auf mehrere Transferdateien aufgeteilt. Transferdateien, die mittels ilidata:... angegeben werden, werden genauso validiert wie lokal vorliegende Transferdateien.
Für mich gehören sie auch zum Transfer. Kataloge und dergleichen gibt es ja nicht gemäss Referenzhandbuch, sondern sie sind eine „künstliche“ Erfindung. Sonst müsste man solche Anwendungsfälle explizit im Referenzhandbuch regeln.
OK, kann man akzeptieren. Dann muss klar sein, dass bei der Serialisierung keine gleichlautenden TID wie in eingebundenen Katalogen geschrieben werden. Merci für die Inputs!
Wir haben das Gleiche Problem in der kommunalen Nutzungsplanung. Der Katalog hat vierstellige IDs und kommt separate daher. Wenn nun der Datenlieferant ebenfalls vierstellige IDs verwendet, gibt es einen Konflikt.
Wir haben nun die Datenlieferanten angewiesen, gültige STANDARDOIDs zu verwenden für das Datenmodell, damit das Problem umgangen werden kann. In der Übergangszeit, bis alle Datensätze umgestellt sind, schalten wir die OID-Prüfung via toml-File aus.
Ah, merci. Aber das sind keine echten OID, sondern normale Attribute, die den Aufbau einer STANDARDOID haben müssen.
CLASS Planung =
Planung_ID : INTERLIS.STANDARDOID;
Name : MANDATORY TEXT*254;
Typ : MANDATORY Planungstyp;
Nummer : TEXT*10;
Gemeinde_ID_BFS : MANDATORY 2761 .. 2895;
Rechtsstatus : MANDATORY RechtsstatusArt;
END Planung;
Die Validierung des Attributs kann man wie beschrieben deaktivieren. Die OID selber ist davon jedoch nicht betroffen, was aus konzeptioneller Sicht durchaus Sinn macht: Jedes Objekt hat per Definition eine Identität.
(oder hat sich das in den sechs Jahren seit der Erfassung