EN15907-XML-Allgemeine Überlegungen - Versionsgeschichte

Mfreiberg am 30. November 2017 um 14:47 Uhr

2017-11-30T14:47:44Z

Dbalzer: /* Allgemeine Fragen */

2017-11-29T08:09:29Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-29T08:07:10Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-29T07:54:40Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-28T20:25:06Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-28T20:08:11Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-28T19:28:43Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-17T21:48:59Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-17T17:36:01Z

‎Allgemeine Fragen

Dbalzer: /* Allgemeine Fragen */

2017-11-17T17:23:46Z

‎Allgemeine Fragen

@@ Zeile 3: / Zeile 3: @@
 Müssen wir das Root-Element [[EN15907-XML-ExchangeSet|ExchangeSet]] in irgendeiner Form in eine der Schemadefinitionen übernehmen? --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
-''Ich votiere dafür. Das verhindert, dass jemand auf die Idee kommt, sich sich ein eigenes Rahmenelement zu backen.'' [[Benutzer:DBalzer|DBalzer]]
+: ''Ich votiere dafür. Das verhindert, dass jemand auf die Idee kommt, sich sich ein eigenes Rahmenelement zu backen.'' [[Benutzer:DBalzer|DBalzer]]
 ----
@@ Zeile 9: / Zeile 11: @@
 Wofür sind die Attribute [[EN15907-XML-Attribut-sourceID|sourceID]] und [[EN15907-XML-Attribut-numeric|numeric]] vorgesehen? --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
-''<code>sourceId</code> bietet die Möglichkeit, Knoten in geschachtelten Datenstrukturen eine Identität zu geben. Bei Exporten aus der DIF-Datenbank wären das die UIDs z.B. von Manifestationen, Titeln, Ereignissen, usw.''
+: ''<code>sourceId</code> bietet die Möglichkeit, Knoten in geschachtelten Datenstrukturen eine Identität zu geben. Bei Exporten aus der DIF-Datenbank wären das die UIDs z.B. von Manifestationen, Titeln, Ereignissen, usw.''
-''Solche Knoten-Identitäten sind nützlich, wenn ähnlich strukturierte Daten aus verschiedenen Quellen zusammengefügt werden sollen. Besonders nützlich sind sie im Hinblick auf eine RDF-Darstellung, wo man sogenannte "blank nodes" zu vermeiden oder zu eliminieren versucht (dort bekannt als Skolemisierung[https://www.w3.org/wiki/BnodeSkolemization]).''
+: ''Die unterschiedlichen Schreibweisen <code>sourceID</code> und <code>sourceId</code> im ersten Schema-Release sollten vereinheitlicht, besser noch in <code>nodeId</code> geändert werden.''
-''Die unterschiedlichen Schreibweisen <code>sourceID</code> und <code>sourceId</code> im ersten Schema-Release sollten vereinheitlicht, besser noch in <code>nodeId</code> geändert werden.''
+: ''Das Attribut <code>numeric</code> ist eine Altlast, die (soweit ich mich erinnere) mal aus dem bibliothekarischen Umfeld in dieses Schema hineingeraten ist. Mir fällt derzeit keine sinnvolle Anwendung dafür ein.'' --[[Benutzer:DBalzer|DBalzer]] ([[Benutzer Diskussion:DBalzer|Diskussion]]) 21:08, 28. Nov. 2017 (CET)
-''Das Attribut <code>numeric</code> ist eine Altlast, die (soweit ich mich erinnere) mal aus dem bibliothekarischen Umfeld in dieses Schema hineingeraten ist. Mir fällt derzeit keine sinnvolle Anwendung dafür ein.''
+:: Danke für die Erläuterungen. Ich votiere für die Änderung von <code>sourceID</code>/<code>sourceId</code> in <code>nodeID</code>. Damit ist der Elementname aussagekräftiger. --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 15:47, 30. Nov. 2017 (CET)
 ----
@@ Zeile 22: / Zeile 25: @@
 Das Schema schreibt den Datentyp <code>xs:anyURI</code> für das Attribut <code>scheme</code> vor. In vielen Fällen wird aber kein URI angegeben werden, z.B. ''UUID'' im Element <code>Identifier</code> oder ''ISIL (ISO 15511)'' im Element <code>SourceIdentifier</code>. Gleiches gilt für das Attribut <code>vocSource</code> in <code>HasAgent/Activity</code>, das mit ''local'' als Defaultwert daherkommt.  --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
-Betr. <code>Identifier</code>: ''ISIL haben einen LOD-Namensraum: [http://sigel.staatsbibliothek-berlin.de/en/suche/linked-data-service/] ; UUIDs haben einen URN-Namensraum (z.B. urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6).''
+: Betr. <code>Identifier</code>: ''ISIL haben einen LOD-Namensraum: [http://sigel.staatsbibliothek-berlin.de/en/suche/linked-data-service/] ; UUIDs haben einen URN-Namensraum (z.B. urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6).''
-''Die DIF-eigenen Vokabulare sind derzeit tatsächlich noch sowas wie "local", aber die sollten eigentlich so bald wie möglich als LOD-Ressource öffentlich referenzierbar gemacht werden. Vor über 5 Jahren hatte ich mal damit angefangen, davon was in einen RDF-Triplestore zu legen (siehe [http://filmstandards.org/fsc/index.php/Filmstandards.org_root_namespace]), aber das ging seinerzeit noch mangels Interesse unter.''
+:: Danke für den Hinweis auf die Namensräume! Sollte das Attribut <code>scheme</code> dann nicht im Fall der UUIDs mit "urn:uuid" und im Fall der ISIL-Nummern mit "http://ld.zdb-services.de/resource/organisations/" belegt werden oder wird das mit den Belegungen "uuid" und "ISIL (ISO 15511)" impliziert?
-''Bis wir durchgängig LOD-URIs haben, werden wir die DIF-eigenen Vokabulare noch als Wertelisten parat halten müssen. Da haben sie wenigstens schon den Namensraum des Anwendungsschemas und eine Typzugehörigkeit.''
+:: Der RDF-Triplestore für das DIF-Vokabular ist höchst interessant. Solange das aber noch nicht spruchreif ist, sollten wir deinem Vorschlag folgen und das Attribut <code>scheme</code> mit "DIF" belegen und im Anwendungsschema die Wertelisten parat halten. --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 15:47, 30. Nov. 2017 (CET)
 ----
@@ Zeile 33: / Zeile 39: @@
 Zur Differenzierung von <code>vocabularySource</code> und <code>vocSource</code> (oder auch von URI- und String-Identifier) schlage ich vor, dass das Schema einen abstrakten Typ <code>VocabularyType</code> definiert und davon zwei Ableitungen: <code>URIVocabularyType</code> und <code>LocalVocabularyType</code>. Ersterer schreibt für den Elementinhalt und das Attribut <code>VocabularySource</code> als Datentyp <code>xs:anyURI</code> vor, letzterer begnügt sich in beiden Fällen mit <code>xs:anyString</code>. In der XML-Instanz werden die vokabularfähigen Elemente dann typisiert. Du kannst am besten beurteilen, ob der Vorschlag eine praktikable Lösung ist.  --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
-''Ja, das sollte irgendwie klarer herausgearbeitet werden. Ich versuche mich mal daran.''
+: ''Ja, das sollte irgendwie klarer herausgearbeitet werden. Ich versuche mich mal daran.''
 ----
@@ Zeile 41: / Zeile 50: @@
 Wie würde Erweiterungen von festen Wertelisten in der ZDB in das Anwendungsschema übernommen werden? Denkbar z.B. beim Typ <code>AgentActivityType</code>.  --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
-''Mir fällt dazu nur eine Versionierung der Anwendungsschemata ein. Solange einzelne Werte in der Datenbank nicht retrospektiv geändert werden (schönere oder treffendere Bezeichnung oder so), wäre das inkrementell zu machen. Neuere Versionen des Anwendungsschemas würden einfach nur zusätzliche Vokabeln als zulässig definieren, alle bisherigen bleiben gültig.
+: ''Mir fällt dazu nur eine Versionierung der Anwendungsschemata ein. Solange einzelne Werte in der Datenbank nicht retrospektiv geändert werden (schönere oder treffendere Bezeichnung oder so), wäre das inkrementell zu machen. Neuere Versionen des Anwendungsschemas würden einfach nur zusätzliche Vokabeln als zulässig definieren, alle bisherigen bleiben gültig.
 ''
-''Retrospektive Änderungen sollten unnötig sein, weil in den Tabellen <code>term</code> und <code>reldef</code> zwischen interner (und damit persistenter) Darstellung und (änderbarer) externer Darstellung für Benutzeroberflächen unterschieden wird.'' --[[Benutzer:DBalzer|DBalzer]] ([[Benutzer Diskussion:DBalzer|Diskussion]]) 20:28, 28. Nov. 2017 (CET)
+: ''Retrospektive Änderungen sollten unnötig sein, weil in den Tabellen <code>term</code> und <code>reldef</code> zwischen interner (und damit persistenter) Darstellung und (änderbarer) externer Darstellung für Benutzeroberflächen unterschieden wird.'' --[[Benutzer:DBalzer|DBalzer]] ([[Benutzer Diskussion:DBalzer|Diskussion]]) 20:28, 28. Nov. 2017 (CET)
-−
 ----
 Wie gehen wir mit den Länderkürzeln um, die nicht Teil von ISO 3166-1 sind? ''DD'', ''D1'', ''D2'' etc. Das Attribut <code>scheme</code> müsste in diesen Fällen anders belegt sein, aber wie?  --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
-''Naiverweise wäre das ein Fall für <code>scheme="local"</code>. In einem bidirektionalen Datenaustausch gibt es aber mehrere Lokalitäten, so dass wir wohl oder übel hier den Urheber des Ländercodes angeben müssen, also z.B. <code>scheme="DIF"</code>.''
+: ''Naiverweise wäre das ein Fall für <code>scheme="local"</code>. In einem bidirektionalen Datenaustausch gibt es aber mehrere Lokalitäten, so dass wir wohl oder übel hier den Urheber des Ländercodes angeben müssen, also z.B. <code>scheme="DIF"</code>.''
-''Mit einer echten LOD-Implementierung wären wir hier besser dran. Dann würde der URI-Namensraum das <code>scheme</code>-Attribut überflüssig machen. Obendrein würde die publizierte RDF-Ressource auch noch angeben können, dass z.B. DIF "DD" äquivalent zu BArch "DDDE" und beides wiederum gleichbedeutend mit [http://www.wikidata.org/entity/Q16957] ist.''--[[Benutzer:DBalzer|DBalzer]] ([[Benutzer Diskussion:DBalzer|Diskussion]]) 08:54, 29. Nov. 2017 (CET)
+:: Das sollte das Ziel sein. Bis dahin arbeiten wir, wie oben schon vorgeschlagen, mit <code>scheme="DIF"</code>. --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 15:47, 30. Nov. 2017 (CET)

← Nächstältere Version		Version vom 29. November 2017, 08:09 Uhr
Zeile 52:		Zeile 52:
	''Naiverweise wäre das ein Fall für <code>scheme="local"</code>. In einem bidirektionalen Datenaustausch gibt es aber mehrere Lokalitäten, so dass wir wohl oder übel hier den Urheber des Ländercodes angeben müssen, also z.B. <code>scheme="DIF"</code>.''		''Naiverweise wäre das ein Fall für <code>scheme="local"</code>. In einem bidirektionalen Datenaustausch gibt es aber mehrere Lokalitäten, so dass wir wohl oder übel hier den Urheber des Ländercodes angeben müssen, also z.B. <code>scheme="DIF"</code>.''

−	''Mit einer echten LOD-Implementierung wären wir hier besser dran. Dann würde der URI-Namensraum das <code>scheme</code>-Attribut überflüssig machen. Obendrein würde die publizierte RDF-Ressource auch noch angeben können, dass z.B. DIF "DD" äquivalent zu BArch "DDDE" und ~~das~~ wiederum gleichbedeutend mit [http://www.wikidata.org/entity/Q16957] ist.''--[[Benutzer:DBalzer\|DBalzer]] ([[Benutzer Diskussion:DBalzer\|Diskussion]]) 08:54, 29. Nov. 2017 (CET)	+	''Mit einer echten LOD-Implementierung wären wir hier besser dran. Dann würde der URI-Namensraum das <code>scheme</code>-Attribut überflüssig machen. Obendrein würde die publizierte RDF-Ressource auch noch angeben können, dass z.B. DIF "DD" äquivalent zu BArch "DDDE" und beides wiederum gleichbedeutend mit [http://www.wikidata.org/entity/Q16957] ist.''--[[Benutzer:DBalzer\|DBalzer]] ([[Benutzer Diskussion:DBalzer\|Diskussion]]) 08:54, 29. Nov. 2017 (CET)

← Nächstältere Version		Version vom 29. November 2017, 08:07 Uhr
Zeile 32:		Zeile 32:

	Zur Differenzierung von <code>vocabularySource</code> und <code>vocSource</code> (oder auch von URI- und String-Identifier) schlage ich vor, dass das Schema einen abstrakten Typ <code>VocabularyType</code> definiert und davon zwei Ableitungen: <code>URIVocabularyType</code> und <code>LocalVocabularyType</code>. Ersterer schreibt für den Elementinhalt und das Attribut <code>VocabularySource</code> als Datentyp <code>xs:anyURI</code> vor, letzterer begnügt sich in beiden Fällen mit <code>xs:anyString</code>. In der XML-Instanz werden die vokabularfähigen Elemente dann typisiert. Du kannst am besten beurteilen, ob der Vorschlag eine praktikable Lösung ist. --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)		Zur Differenzierung von <code>vocabularySource</code> und <code>vocSource</code> (oder auch von URI- und String-Identifier) schlage ich vor, dass das Schema einen abstrakten Typ <code>VocabularyType</code> definiert und davon zwei Ableitungen: <code>URIVocabularyType</code> und <code>LocalVocabularyType</code>. Ersterer schreibt für den Elementinhalt und das Attribut <code>VocabularySource</code> als Datentyp <code>xs:anyURI</code> vor, letzterer begnügt sich in beiden Fällen mit <code>xs:anyString</code>. In der XML-Instanz werden die vokabularfähigen Elemente dann typisiert. Du kannst am besten beurteilen, ob der Vorschlag eine praktikable Lösung ist. --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
		+
		+	''Ja, das sollte irgendwie klarer herausgearbeitet werden. Ich versuche mich mal daran.''
		+
		+	''Mit einer echten LOD-Implementierung würden solche Probleme von selbst verschwinden, denn da wird jedes Vokabularelement, egal ob weltbekannt oder gerade eben ausgedacht, als URI referenziert.''--[[Benutzer:DBalzer\|DBalzer]] ([[Benutzer Diskussion:DBalzer\|Diskussion]]) 09:07, 29. Nov. 2017 (CET)

	----		----

← Nächstältere Version		Version vom 29. November 2017, 07:54 Uhr
Zeile 45:		Zeile 45:

	Wie gehen wir mit den Länderkürzeln um, die nicht Teil von ISO 3166-1 sind? ''DD'', ''D1'', ''D2'' etc. Das Attribut <code>scheme</code> müsste in diesen Fällen anders belegt sein, aber wie? --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)		Wie gehen wir mit den Länderkürzeln um, die nicht Teil von ISO 3166-1 sind? ''DD'', ''D1'', ''D2'' etc. Das Attribut <code>scheme</code> müsste in diesen Fällen anders belegt sein, aber wie? --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
		+
		+	''Naiverweise wäre das ein Fall für <code>scheme="local"</code>. In einem bidirektionalen Datenaustausch gibt es aber mehrere Lokalitäten, so dass wir wohl oder übel hier den Urheber des Ländercodes angeben müssen, also z.B. <code>scheme="DIF"</code>.''
		+
		+	''Mit einer echten LOD-Implementierung wären wir hier besser dran. Dann würde der URI-Namensraum das <code>scheme</code>-Attribut überflüssig machen. Obendrein würde die publizierte RDF-Ressource auch noch angeben können, dass z.B. DIF "DD" äquivalent zu BArch "DDDE" und das wiederum gleichbedeutend mit [http://www.wikidata.org/entity/Q16957] ist.''--[[Benutzer:DBalzer\|DBalzer]] ([[Benutzer Diskussion:DBalzer\|Diskussion]]) 08:54, 29. Nov. 2017 (CET)

@@ Zeile 22: / Zeile 22: @@
 Das Schema schreibt den Datentyp <code>xs:anyURI</code> für das Attribut <code>scheme</code> vor. In vielen Fällen wird aber kein URI angegeben werden, z.B. ''UUID'' im Element <code>Identifier</code> oder ''ISIL (ISO 15511)'' im Element <code>SourceIdentifier</code>. Gleiches gilt für das Attribut <code>vocSource</code> in <code>HasAgent/Activity</code>, das mit ''local'' als Defaultwert daherkommt.  --[[Benutzer:Mfreiberg|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
-Betr. <code>Identifier</code>: ''ISIL haben einen LOD-Namensraum: [http://sigel.staatsbibliothek-berlin.de/en/suche/linked-data-service/] ; UUIDs haben einen URN-Namensraum (z.B. urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6).'' [[Benutzer:DBalzer|DBalzer]]
+Betr. <code>Identifier</code>: ''ISIL haben einen LOD-Namensraum: [http://sigel.staatsbibliothek-berlin.de/en/suche/linked-data-service/] ; UUIDs haben einen URN-Namensraum (z.B. urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6).''
 ----

← Nächstältere Version		Version vom 28. November 2017, 20:08 Uhr
Zeile 8:		Zeile 8:

	Wofür sind die Attribute [[EN15907-XML-Attribut-sourceID\|sourceID]] und [[EN15907-XML-Attribut-numeric\|numeric]] vorgesehen? --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)		Wofür sind die Attribute [[EN15907-XML-Attribut-sourceID\|sourceID]] und [[EN15907-XML-Attribut-numeric\|numeric]] vorgesehen? --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
		+
		+	''<code>sourceId</code> bietet die Möglichkeit, Knoten in geschachtelten Datenstrukturen eine Identität zu geben. Bei Exporten aus der DIF-Datenbank wären das die UIDs z.B. von Manifestationen, Titeln, Ereignissen, usw.''
		+
		+	''Solche Knoten-Identitäten sind nützlich, wenn ähnlich strukturierte Daten aus verschiedenen Quellen zusammengefügt werden sollen. Besonders nützlich sind sie im Hinblick auf eine RDF-Darstellung, wo man sogenannte "blank nodes" zu vermeiden oder zu eliminieren versucht (dort bekannt als Skolemisierung[https://www.w3.org/wiki/BnodeSkolemization]).''
		+
		+	''Die unterschiedlichen Schreibweisen <code>sourceID</code> und <code>sourceId</code> im ersten Schema-Release sollten vereinheitlicht, besser noch in <code>nodeId</code> geändert werden.''
		+
		+	''Das Attribut <code>numeric</code> ist eine Altlast, die (soweit ich mich erinnere) mal aus dem bibliothekarischen Umfeld in dieses Schema hineingeraten ist. Mir fällt derzeit keine sinnvolle Anwendung dafür ein.''
		+	--[[Benutzer:DBalzer\|DBalzer]] ([[Benutzer Diskussion:DBalzer\|Diskussion]]) 21:08, 28. Nov. 2017 (CET)

	----		----

← Nächstältere Version		Version vom 17. November 2017, 21:48 Uhr
Zeile 12:		Zeile 12:

	Das Schema schreibt den Datentyp <code>xs:anyURI</code> für das Attribut <code>scheme</code> vor. In vielen Fällen wird aber kein URI angegeben werden, z.B. ''UUID'' im Element <code>Identifier</code> oder ''ISIL (ISO 15511)'' im Element <code>SourceIdentifier</code>. Gleiches gilt für das Attribut <code>vocSource</code> in <code>HasAgent/Activity</code>, das mit ''local'' als Defaultwert daherkommt. --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)		Das Schema schreibt den Datentyp <code>xs:anyURI</code> für das Attribut <code>scheme</code> vor. In vielen Fällen wird aber kein URI angegeben werden, z.B. ''UUID'' im Element <code>Identifier</code> oder ''ISIL (ISO 15511)'' im Element <code>SourceIdentifier</code>. Gleiches gilt für das Attribut <code>vocSource</code> in <code>HasAgent/Activity</code>, das mit ''local'' als Defaultwert daherkommt. --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
		+
		+	Betr. <code>Identifier</code>: ISIL haben einen LOD-Namensraum: [http://sigel.staatsbibliothek-berlin.de/en/suche/linked-data-service/] ; UUIDs haben einen URN-Namensraum (z.B. urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6). [[Benutzer:DBalzer\|DBalzer]] ([[Benutzer Diskussion:DBalzer\|Diskussion]])

	----		----

← Nächstältere Version		Version vom 17. November 2017, 17:23 Uhr
Zeile 2:		Zeile 2:

	Müssen wir das Root-Element [[EN15907-XML-ExchangeSet\|ExchangeSet]] in irgendeiner Form in eine der Schemadefinitionen übernehmen? --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)		Müssen wir das Root-Element [[EN15907-XML-ExchangeSet\|ExchangeSet]] in irgendeiner Form in eine der Schemadefinitionen übernehmen? --[[Benutzer:Mfreiberg\|Mfreiberg]] ([[Benutzer Diskussion:Mfreiberg\|Diskussion]]) 16:41, 17. Nov. 2017 (CET)
		+
		+	Ich votiere dafür. Das verhindert, dass jemand auf die Idee kommt, sich sich ein eigenes Rahmenelement zu backen. [[Benutzer:DBalzer\|DBalzer]] ([[Benutzer Diskussion:DBalzer\|Diskussion]])