Ältere Versionen von GAEB DA XML

In der Version gibt es für jede Datenaustauschphase ein eigenes Schema.
Das gilt auch für die Datenaustauschphasen X81, X82, X83, X85, X86 und X87.

Jede Datenaustauschphase hat einen eigenen Namensraum, z.B.
„http://www.gaeb.de/GAEB_DA_XML/DA81/3.2“ – für X81
„http://www.gaeb.de/GAEB_DA_XML/DA82/3.2“ – für X82
usw.

Die Schemata für die Datenaustauschphasen X81, X82, X83, X85, X86 und X87 unterscheiden sich im Moment
lediglich durch den Namensraum und den Wert des Elementes DA.

Damit die gleichen Teile der einzelnen Austauschphasen nicht in jedes Schema kopiert
und in Zukunft mehrfach gepflegt werden müssen, sind diese Teile in eine Bibliothek ausgelagert.
Die Schemata für die Datenaustauschphasen X81, X82, X83, X85, X86 und X87 importieren jeweils
eine Bibliothek mit diesen gemeinsamen Teilen. Die eigentliche Schemadatei definiert dann
nur noch die Abweichungen gegenüber der Bibliothek. Das sind meist nur der Namensraum
und der Inhalt des Feldes DA.

Die Signatur wurde in allen Austauschphasen entfernt. Das entsprechende Schema wird nicht mehr importiert.

Die Datei xml.xsd wird nicht mehr importiert.
Die GAEB XML-Gruppe vermutet, dass für unsere Belange diese Datei nicht benötigt wird.

Erläuterung der Begriffe:

<GAEB>

Wurzelelement

<GAEB>/<GAEBInfo>

Element mit grundsätzlichen Informationen zur Instanz der Datenaustauschdatei

<GAEBInfo>/<Version>

Version des GAEB-Datenaustausches

<GAEBInfo>/<VersDate>

Datum der Ausgabe des GAEB-Datenaustausches

<GAEBInfo>/<Date>

Datum des Tages, an dem die GAEB-Datei erzeugt wurde

<GAEBInfo>/<Time>

Uhrzeit, zu der die GAEB-Datei erzeugt wurde

<GAEBInfo>/<ProgSystem>

Anwenderprogramm, mit dem die GAEB-Datei erzeugt wurde

<GAEBInfo>/<ProgName>

Programmkomponente, die diese GAEB-Datei erzeugt hat, z.B. GAEB-Toolbox

<GAEBInfo>/<Certific>

Angabe, ob das Anwenderprogramm, welches in ProgSystem steht,

bezüglich des GAEB Datenaustausches für die Phase 31 zertifiziert ist.

<GAEB>/<QtyDeterm>

Element mit Informationen zur Mengenermittlung

<QtyDeterm>/<QtyDetermInfo>

Informationen zur Mengenermittlung

<QtyDetermInfo>/<MethodDescription>

Benutze Verfahrensbeschreibung

<QtyDetermInfo>/<OrdDescr>

Bezeichnung des Auftrags (optional)

<QtyDetermInfo>/<ProjDescr>

Bezeichnung der Baumaßnahme

<QtyDetermInfo>/<ServiceProvisionStartDate>

Beginn der Leistungserbringung

<QtyDetermInfo>/<ServiceProvisionEndDate>

Ende der Leistungserbringung

<QtyDetermInfo>/<Creator>

Adresse des Erstellers

<QtyDetermInfo>/<Profiler>

Adresse des Prüfers

<QtyDeterm>/<DP>

Datenaustauschphase; hier ist nur „31“ zulässig

<QtyDeterm>/<OWN>

Informationen zum Auftraggeber

<QtyDeterm>/<CTR>

Informationen zum Auftragnehmer

<QtyDeterm>/<AddText>

Zusätzliche Textinformationen (Optional)

<QtyDeterm>/<BoQ>

Leistungsverzeichnis inkl. der Mengenermittlung

<BoQ>/<BoQBkdn>

Information zur Gliederung des Leistungsverzeichnisses

<BoQ>/<BoQBody>

Leistungsverzeichnis-Hauptteil

<BoQ>/<BoQCtgy>

Leistungsverzeichnis-Bereich

<BoQBody>/<Itemlist>

Positionsliste

<Itemlist>/<Item>

Position

<Item>/<Qty>

Aufmassmenge. Das Ergebnis der Liste der Mengenermittlung kann mitgeliefert werden. Dadurch kann auch nur eine Aufmassmenge ohne Mengenermittlungszeilen übertragen werden. Die Aufmassmenge muss nicht identisch mit dem Ergebnis der Mengenermittlungszeilen sein.

<Item>/<QDetermltem>

Liste der Mengenermittlungszeilen

<QDetermltem>/<QTakeoff>

​Mengenermittlungszeile

Die Mengenermittlungszeile wird im Element QTakeoff als Wert des Attributs Row abgelegt.
Der Attributwert enthält immer 80 Zeichen.
Die Zeichen 1 bis 2 für die DA sind immer Leerzeichen, da hier keine Angabe erfolgt.
Die Zeichen 3 bis 11 für die Ordnungszahl sind immer Leerzeichen, da auch hier keine Angabe erfolgt.
Die Zeichen 12 bis 80 entsprechen von ihrer Bedeutung her genau den Zeichen 12 bis 80 der Zeile der REB-Datei (DA11).

Um Missverständnissen vorzubeugen, sei hier noch einmal erwähnt, dass die Zeichen im Attributwert, wie auch alle weiteren Zeichen der X31-Datei, im Zeichensatz der X31-Datei abgelegt werden. In der Praxis ist dies häufig UTF-8 oder UTF-16.

<QDetermltem>/<CtlgAssign>

Katalogzuordnung (Optional)

---

X31 Änderungen gegen BetaV3.2-1

• In tgQTakeoffRow die Pattern von “ {2,2} {11,11}.{67,67}“ auf “ {2,2} {9,9}.{69,69}“ gesetzt
• tgQDetermItem und tgQTakeoffRow in die Lib übernommen unf hier gelöscht
• tgQtyDeterm umbenannt in tgQtyDetermination wegen Konflikt in Lib

Downloads finden sie im Downloadbereich

Erläuterung der Begriffe:

<GAEB>

Wurzelelement

<GAEB>/<GAEBInfo>

Element mit grundsätzlichen Informationen zur Instanz der Datenaustauschdatei

<GAEBInfo>/<DP>

Datenaustauschphase; hier ist nur „61“ zulässig

<GAEBInfo>/<Version>

Version des GAEB GAEB-Datenaustausches

<GAEBInfo>/<VersDate>

Datum der Ausgabe des GAEB-Datenaustausches

<GAEBInfo>/<Date>

Datum das Tages, an dem die GAEB-Datei erzeugt wurde

<GAEBInfo>/<Time>

Uhrzeit, zu der die GAEB-Datei erzeugt wurde

<GAEBInfo>/<ProgSystem>

Anwenderprogramm, mit dem die GAEB-Datei erzeugt wurde

<GAEBInfo>/<ProgName>

Programmkomponente, die diese GAEB-Datei erzeugt hat, z.B. GAEB-Toolbox

<GAEBInfo>/<Certific>

Angabe, ob das Anwenderprogramm, welches in ProgSystem steht,
bezüglich des GAEB Datenaustausches für die Phase 61 zertifiziert ist.

<PrjInfo>

Allgemeine Angaben zum Projekt

<PrjInfo>/<NamePrj>

Einzeiliger, max. 60stelliger Identifikator des Projektes. Dieser Identifikator sollte innerhalb des Büros,
in dem das Projekt bearbeitet wird, eindeutig sein.

<PrjInfo>/<LblPrj>

Einzeiliger, max 100stelliger Text, der das Projekt näher bezeichnet. Dieser Text soll nicht dazu dienen,
das Projekt im Büro des Bearbeiters eindeutig zu identifizieren.

<PrjInfo>/<Description>

Mehrzeiliger Text, in dem beliebige, ausführliche Bemerkungen zum Projekt eingetragen werden können.
Dieser Text kann in mehrere jeweils beliebig Lange Zeilen aufgeteilt werden. Formatierungen innerhalb
der Zeilen sind nicht zulässig. Das auswertende Programm darf bei der Anzeige oder in Berichten Zeilen
nach Bedarf umbrechen. Die Umbrüche sollten, wenn möglich, nach Leerzeichen erfolgen. Zwischen zwei
Line Elementen ist der Umbruch in der Anzeige und in Berichten zwingen.

<SpatialHierarchy>

Raumbuch

<SpatialHierarchy>/<SpatialHierarchyInfo>

Kopfdaten zum Raumbuch

Hier werden Strukturinformationen, Informationen zu benutzten Katalogen und beschreibende Informationen
zum Raumbuch abgelegt. Informationen zu Instanzen wie konkreten Gebäuden, Geschossen oder Räumen
stehen hier nicht. Diese Informationen stehen unterhalb des Elementes Body.

<SpatialHierarchyInfo>/<Topology>

Gliederungsebenen

In diesem Element wird die Gliederung des Raumbuches definiert. Die beiden untergeordneten
Elemente Group und CompositionTyp sollen so verwendet werden, wie das bei IFC vorgesehen ist.
Damit ist gewährleiste, dass die Struktur für ein Raumbuch aus einer IFC-Datei übernommen werden kann.
Das gilt mit folgender Ausnahme: In IFC-Dateien ist es möglich, 12 unterschiedlich Gliederungsebenen zu verwenden.
Von diesen 12 Ebenen dürfen im Raumbuch nur 10 genutzt werden. Diese Nebenbedingung ist durch eine
der oben genannten Regeln abgesichert. Eine Ebene wird eindeutig definiert durch die Werte
in den Elementen Group und CompositonType.

<Topology>/attribute name=“Group“

Die Gliederungsebenen des Raumbuches werden konkret bezeichnet. Die Bezeichnung setzt sich
aus zwei Teilen zusammen, Group und CompositonType. Beide Begriffe werden in IFC genau so bezeichnet.
Die Kombination der zulässigen Begriffe für Group und CompositonType ergibt 12 unterschiedliche Ebenen.
Für Group sind die folgenden Begriffe zugelassen:

• Site
• Building
• BuildingStorey
• Space

<Topology>/attribute name=“CompositonType“

Die Gliederungsebenen des Raumbuches werden konkret bezeichnet. Die Bezeichnung setzt sich
aus zwei Teilen zusammen, Group und CompositonType. Beide Begriffe werden in IFC genau so bezeichnet.
Die Kombination der zulässigen Begriffe für Group und CompositonType ergibt 12 unterschiedliche Ebenen.
Für CompositonType sind die folgenden Begriffe zugelassen:

• Element
• Partial
• Complex

<CatalogDescription>

Für jeden Katalog, auf den in der Raumbuchinstanz verwiesen wird, muss ein Element <CatalogDescription>
existieren. In diesem Element stehen verschiedenen Metadaten für den betreffenden Katalog.

<CatalogDescription>/attribute name=“Alias“

Damit nicht in der Raumbuchinstanz (im Element Body) an jedem Verweis die Metadaten des Kataloges
wiederholt werden müssen, gibt es für jeden benutzten Katalog einen Alias. Der Alias kann viel kürzer
als die Metadaten sein. Damit wird das gesamte XML-Dokument kürzer. Außerdem werden Redundanzen vermieden.

<CatalogDescription>/attribute name=“CatalogType“

In diesem Attribut wird konkret angegeben, um welchen Katalogtyp es sich handelt. Diese Informationen helfen
auswertenden Programmen, Kataloginformationen zu interpretieren. Folgende Katalogtypen sind zugelassen:

• DIN 276-1
• DIN 277-2
• STLB-Bau
• DBD-KE
• DBD-KK
• Z-Merkmal
• Z-Artikel
• SpatialHirarchy
• UserDefined

Der CatalogType gibt nur den Typ des Kataloges an. Eine Version wird hier nicht verschlüsselt.
leiche Katalogtypen unterschiedlicher Versionen müssen sich in der ID unterscheiden.
Die einzelnen Katalogtypen stehen für folgende Kataloge:

• „DIN 276-1“ steht für die in der DIN 276 Teil 1 veröffentlichten Kostengliederung.
• „DIN 277-2“ steht für die in der DIN 277 Teil 2 veröffentlichten Gliederung der Netto­Grundfläche
• „STLB-Bau“ steht für das vom DIN herausgegebene Standardleistungsbuch Bau
• „DBD-KE“ steht für die von Schiller & Partner herausgegebenen DBD-KostenElemente
• „DBD-KK“ steht für das von Schiller & Partner herausgegebene DBD-Kostenkalkül
• „Z-Merkmal“ steht für den Zentralen ISYBau Katalog Merkmale
• „Z-Artikel“ steht für den Zentralen ISYBau Katalog Artikel
• „SpatialHirarchy“ steht für in dieser Raumbuchdefinition festgelegte Katalogwerte
• „UserDefined“ steht für hier nicht definierte Kataloge. In diesem Fall müssen sich die Austauschpartner

über die Interpretation der entsprechenden Katalogverweise verständigen.

<CatalogDescription>/attribute name=“ID“

Die ID identifiziert den Katalog eindeutig. Sie muss vom Herausgeber des Kataloges vergeben werden.

Diese ID soll weltweit eindeutig sein. Dafür bieten sich zwei Verfahren an.

Die ID kann eine GUID sein. Eine GUID ist immer weltweit eindeutig. Allerdings kann eine GUID
vom Menschen nicht gelesen werden. Aus einer GUID kann keiner Rückschluss auf einen Herausgeber,
den Inhalt oder die Version eines Kataloges gezogen werden.

Die ID kann aus einer auf den Herausgeber angemeldeten Domain abgeleitet werden.
Damit kann abgesichert werden, dass unterschiedliche Herausgeber unterschiedliche Domains haben.
Im Normalfall wird ein Herausgeber mehrere Kataloge in unterschiedlichen Versionen herausgeben.
Es unterliegt bei diesem Verfahren der Disziplin des Herausgebers, dafür zu sorgen,
dass alle von Ihm herausgegebenen Kataloge unterschiedlich IDs haben.

• Hier einige Beispiele, wie eine ID aussehen könnte:
• 2C43916B-FB4B-4F76-889A-F22C105E6050
• FF858196-968B-49F1-9F5A-C85D439EE1A6
• www.din.de/DIN276-1/2008-12
• www.din.de/DIN277-2/DIN 277-2_2005-02
• www.din.de/STLB-Bau/2011-10

<CatalogDescription>/attribute name=“Code“

Ein kurzer, für den Menschen lesbarer Text, der Rückschlüsse auf den Katalog zuläßt.
Beispiele:

• DIN 276 2008-12
• DIN 277 2005-02
• STLB-Bau 2011-10
• DBD-Kostenelemente
• DBD-Kostenkalkül

<CatalogDescription>/attribute name=“Name“

Etwas längerer, einzeiliger, für den Menschen lesbarer Text, der den Katalog beschreibt.
Beispiele:

• Grundflächen und Rauminhalte von Bauwerken im Hochbau
  Kosten im Bauwesen – Teil 1: Hochbau

<CatalogDescription>/<Description>

Ausführlicher, ggf. mehrzeiliger Text zur Beschreibung des Kataloges
Beispiel:

• Grundflächen und Rauminhalte von Bauwerken im Hochbau –
  Teil 2: Gliederung der Netto­Grundfläche
  (Nutzflächen, Technische Funktionsflächen und Verkehrsflächen)

<Body>

Instanzen von Ebenen, Bauteilen, Ausstattungen usw.

<Body>/<TopologyElement>

Ebenen im Raumbuch. Die Ebenen können geschachtelt werden. Jede Schachtelung entspricht einer
Gliederungsebenen, die unter <SpatialHierarchyInfo>/<Topology> definiert wurde. Das bedeutet, die
<TopologyElement>-Elemente die unmittelbar unter <Body> stehen entsprechen dem ersten <Topology>-Element
unterhalb von <SpatialHierarchyInfo>.

Die <TopologyElement>-Elemente der ersten geschachtelten Ebene entsprechen dem zweiten <Topology>-Element
unterhalb von <SpatialHierarchyInfo>.

Die <TopologyElement>-Elemente der zweiten geschachtelten Ebene entsprechen dem dritten <Topology>-Element
unterhalb von <SpatialHierarchyInfo> usw. Damit diese Zuordnung stimmt, darf keine Schachtelungseben ausgelassen
werden. Ein Mechanismus, wie die ausgelassen Hierarchiestufen bei einem LV ist hier nicht vorgesehen.

<TopologyElement>/attribute name=“ID“

Jede Ebenen benötigt einen eindeutigen Identifikator. Dieser Identifikator sollte eine GUID sein.

Wird das Raumbuch aus einem bereits existierenden Gebäudemodell erzeugt, z.B. aus einer IFC-Datei, dann sind
die in der IFC-Datei existierenden GlobalIDs zu verwenden.

<TopologyElement>/attribute name=“Code“

Hier soll ein kurzer, für den Menschen lesbarer Text stehen. Dieser Text muss auf einer Ebenen eindeutig sein.
In einem Geschoss darf es beispielsweise nicht zwei Räume geben, die den gleichen Code haben.

Wird das Raumbuch aus einem bereits existierenden Gebäudemodell erzeugt, z.B. aus einer IFC-Datei, dann sollte
hier der Inhalt des Feldes Name übernommen werden. Wenn in der IFC-Datei im Feld Name ein Text steht, der zu lang
ist für den Code, dann soll dieser Konflikt dem Nutzer sichtbar gemacht werden. Der Konflikt kann nur durch Bedienereigriff
gelöst werden. Einfaches Abschneiden der Zeichenkette kann nicht zu einem Text führen, der inhaltlich den Ansprüchen für
Code genügt.

<TopologyElement>/attribute name=“Name“

Hier darf eine ausführlicher einzeilige Beschreibung stehen.

Wird das Raumbuch aus einem bereits existierenden Gebäudemodell erzeugt, z.B. aus einer IFC-Datei, dann sollte
hier der Inhalt des Feldes Name übernommen werden.

<TopologyElement>/<Description>

Ausführlicher, ggf. mehrzeiliger Text zur Beschreibung des <TopologyElement> (der Ebene).

Wird das Raumbuch aus einem bereits existierenden Gebäudemodell erzeugt, z.B. aus einer IFC-Datei, dann sollte
hier der Inhalt des Feldes Description übernommen werden.

<TopologyElement>/<BuildingElement>

Bauteil/Austattung welche dem betrffenden <BuildingElement> (der Ebene) zugeordnet sind.

<BuildingElement>/attribute name=“BuildingElementType“

Jedes Bauteil/Ausstattung ist einem BuildingElementTyp zugeordnet. Dabei sind ausschließlich die als Enumeration
hinterlegten Werte zulässig. Alle hinterlegten Werte entsprechen IFC-Objekten. Einige dieser IFC-Objekte existieren
erst ab der IFC-Version 2×4. Die BuildingElementTypen sind in genau dem Sinne zu verstehen, wie Sie in IFC definiert
sind. Bezüglich der Bedeutung wird an dieser Stelle auf die IFC-Dokumentation verwiesen.

<BuildingElement>/attribute name=“ID“

Jedes <BuildingElement> benötigt einen eindeutigen Identifikator. Dieser Identifikator sollte eine GUID sein.

Wird das Raumbuch aus einem bereits existierenden Gebäudemodell erzeugt, z.B. aus einer IFC-Datei, dann sind
die in der IFC-Datei existierenden GlobalIDs zu verwenden.

<BuildingElement>/attribute name=“Name“

Hier darf eine einzeilige Beschreibung stehen.

Wird das Raumbuch aus einem bereits existierenden Gebäudemodell erzeugt, z.B. aus einer IFC-Datei, dann sollte
hier der Inhalt des Feldes Name aus der IFC-Datei übernommen werden.

Wenn in der IFC-Datei im Feld Name ein Text steht, der zu lang ist für <BuildingElement>/attribute name=“Name“,
dann soll dieser Konflikt dem Nutzer sichtbar gemacht werden.

<BuildingElement>/attribute name=“Material“

Jedem <BuildingElement> (Bauteil/Ausstattung) kann ein Material zugewiesen werden. Als Material sind ausschließlich
die in einer enumeration als deutsche Bezeichnungen hinterlegten Begriffe zulässig. Falls keiner dieser Begriffe das
Material des <BuildingElement> (Bauteil/Ausstattung) beschreibt, kann das Attribut entfallen.

<BuildingElement>/<Description>

Ausführlicher, ggf. mehrzeiliger Text zur Beschreibung des <BuildingElement>/ (Bauteil/Ausstattung). Wird das
Raumbuch aus einem bereits existierenden Gebäudemodell erzeugt, z.B. aus einer IFC-Datei, dann sollte hier der
Inhalt des Feldes Description übernommen werden.

<BuildingElement>/<CatalogReference>

Verweis auf einen Eintrag in einem Katalog

Es ist nur zulässig, auf Einträge aus Katalogen zu verweisen, die unter
<SpatialHierarchyInfo> (Kopfdaten zum Raumbuch)/ <CatalogDescription> aufgeführt sind und dort einen Alias
erhalten haben.

<CatalogReference>/attribute name=“CatalogAlias“

Hier muss der Alias stehen, der unter <SpatialHierarchyInfo> (Kopfdaten zum Raumbuch)/ <CatalogDescription>
dem betreffenden Katalog zugewiesen wurde.

<CatalogReference>/attribute name=“IDRef“

Hier muss eine ID stehen, die in dem betreffenden Katalog auf den Eintrag verweist.

Bei einem Verweis auf einen Eintrag im DIN 276 Katalog könnte das z.B. „342“ sein.

Bei einem Verweis auf einen Eintrag im DIN 277 Katalog könnte das z.B. „1.1“ sein.

Bei einem Verweis auf einen Eintrag im Z-Merkmal Katalog könnte das z.B. „ZR.14.2.102“ sein.

Bei einem Verweis auf einen Eintrag im Z-Artikel Katalog könnt das z.B. „Z.G3.34.5.23.101“ sein.

Bei einem Verweis auf eine STLB-Bau Beschreibung könnten Einträge so aussehen:

• G3056 (entspricht Teilleistungsgruppe 3056)
• P1V25 (entspricht Beschreibungsmerkmal 1, Ausprägung 55)
• P2138V3 (entspricht Beschreibungsmerkmal 2138, Ausprägung 3)
• UP (entspricht Einheitspreis)
• QT (entspricht Menge)

Bei einem Verweis auf ein DBD-Kostenelement könnte ein Eintrag so aussehen:

• G154 (entspricht der Bauteilgruppe 154)
• P2V3 (entspricht dem Beschreibungsmerkmal 2, Ausprägung 3)
• btf
• NetWallArea
• Flaeche

Bei einem Verweis auf DBD-Kostenkalkül könnten Einträge so aussehen:

• Laenge
• Hoehe
• Flaeche

<CatalogReference>/attribute name=“Name“

Hier kann ein beliebig langer einzeiliger Text stehen. Dieser Text soll den Verweis in den Katalog beschreiben.

An dieser Stelle ist auf die Lizenzbedingungen der Kataloghersteller zu achten. Produkte die vom DIN vertrieben
werden unterliegen speziellen Lizenzbedingungen. So dürfen beispielsweise Normen oder STLB-Bau Langtexte nur
unter bestimmten Bedingungen weitergegeben werden.

<CatalogReference>/attribute name=“SetID“

Die SetID dient dazu, zusammengehörende Katalogreferenzen zu kennzeichnen.

Alle Katalogverweise mit der gleichen SetID gehören zusammen. Hierüber können beispielsweise alle zu einer
STLB-Bau Position gehörenden Merkmale gekennzeichnet werden.

<CatalogReference>/<TextValue>

Jeder Katalogverweis kann einen Wert haben. Ein Element <TextValue> existiert dann, wenn der Wert durch einen
Text beschrieben wird. Das kann z.B. der Text der Ausprägung beim STLB-Bau sein.

<CatalogReference>/<NumValue>

Jeder Katalogverweis kann einen Wert haben. Ein Element <NumValue> existiert dann, wenn es sich hierbei um
eine Zahl handelt. Das sind beispielsweise Zahlenwerte für Fläche oder Längen

<CatalogReference>/<DateValue>

Jeder Katalogverweis kann einen Wert haben. Ein Element <DateValue> existiert dann, wenn es sich hierbei um ein
Datum handelt.

<CatalogReference>/<NumValue>/attribute name=“Unit“

 

<CatalogReference>/<NumValue>/attribute name=“Messgroesse“

 

<CatalogReference>/<NumValue>/attribute name=“Value“

 

<CatalogReference>/<NumValue>/<CatalogReference>/

<CatalogReference>/<NumValue>/<CatalogReference>/attribute name=“CatalogAlias“

 

<CatalogReference>/<NumValue>/<CatalogReference>/attribute name=“IDRef“

 

<NumValue>/<Expression>/attribute name=“CatalogAlias“

 

<NumValue>/<Expression>/<Line>

 

<CatalogReference>/<DateValue>

---

Regeln:

Die folgenden Regeln müssen eingehalten sein, wenn die Austauschdatei gültig sein soll.
Viele oder alle der folgenden Regeln sind nicht im Schema abgebildet.
Das bedeutet, dass ein Parser, der eine Instanzdatei gegen das Schema prüft,
Verletzungen dieser Regeln nicht erkennen kann.

X61.1 <Topology>

Das Element Topology hat die Attribute Group und CompositionTyp.
Die zulässigen Werte dieser Attribut sind im Schema als enumeration definiert.
Für diese Werte gilt die folgende Ordnung:

 Ordnung Group          CompositionType

    1    Site           Complex

    2    Site           Element

    3    Site           Partial

 

    4    Building       Complex

    5    Building       Element

    6    Building       Partial

 

    7    BuildingStorey Complex

    8    BuildingStorey Element

    9    BuildingStorey Partial

 

   10    Space          Complex

   11    Space          Element

   12    Space          Partial

Die Ordnung der Werte der Attribut Group und CompositionTyp eines Topology-Elementes muss größer
sein als die Ordnung der Werte der Attribut Group und CompositionTyp des vorhergehenden Topology-Elementes.

Fehlertext

Das Topology Element mit dem Attribut Group=<Wert> und CompositionType=<Wert>
ist an dieser Stelle nicht zulässig.

X61.2 <Topology>

 Es muss mindestens ein Topology-Element der Ordnung 11 mit dem Attribut
Group=“Space“ und CompositionType=“Element“ existieren.

Fehlertext

Es existiert kein Topology-Element mit den Attributen Group=“Space“ und CompositionType=“Element“

X61.3 <TopologyElement>

Die XPath Abfrage: ancestor-or-self::TopologyElement liefert eine Anzahl von <TopologyElement>.
Für kein <TopologyElement> darf diese Anzahl größer sein als die Anzahl der Elemente <Topology>.

Fehlertext

Im Body existieren mehr Gliederungsebenen (TopologyElemente) als in SpatialHierarchyInfo definiert sind.

X61.4 <TopologyElement> 

Jedes <TopologyElement> ist einem Element <Topology> zugeordnet. Hierbei gilt:

• das <TopologyElement> auf der obersten Ebene ist dem ersten Element <Topology> zugeordnet.
• das <TopologyElement> auf der zweiten Ebene ist dem zweiten Element <Topology> zugeordnet.
• das <TopologyElement> auf der dritten Ebene ist dem dritten Element <Topology> zugeordnet.

usw.
Das <TopologyElement>, dem ein Element <Topology> mit den Attributen Group=”Space” und
CompositionType=“Element“ zugeordnet ist, muss mindestens drei Unterelement <CatalogReference>
mit folgenden Inhalten haben:

<TopologyElement Code=“???“ ID=“???“ Name=“???“>

     <CatalogReference IDRef=“SpaceArea“ CatalogAlias=“*1″>

        <NumValue Unit=“m2″ Value=“???“/>

    </CatalogReference>

    <CatalogReference IDRef=“SpacePerimeter“ CatalogAlias=“*1″>

        <NumValue Unit=“m“ Value=“???“/>

    </CatalogReference>

     <CatalogReference IDRef=“SpaceHeight“ CatalogAlias=“*1″>

        <NumValue Unit=“‚m'“ Value=“???“/>

    </CatalogReference>

</TopologyElement>

Hierbei bedeuten:

• ??? – beliebige nutzerspezifische Informationen
• *1 – ein Aliasname; Dieser Aliasname muss im Attribut Alias eines Elementes <CatalogDescription> definiert sein,
  in welchem als Catalogtyp=“SpetialHirarchy“ steht.

Fehlertext

Beim Raum Code=“???“, Name=“???“ fehlt:

[- die Raumfläche (SpaceArea)]|[- der Raumumfang (SpacePerimeter)]|[- die Raumhöhe (SpaceHeight)]

X61.5 <CatalogReference> Attribut IDRef für CatalogType=“DIN 276-1″

Wenn das Attribut Alias von <CatalogReference> mit dem Attribut Alias von einem Element <CatalogDescription>

mit dem Attribut CatalogType=“DIN 276-1″ übereinstimmt, dann muss der Wert im

Attribut IDRef des Elementes <CatalogReference> dem folgenden Regulären Ausdruck entsprechen:

[1-9]\d\d

Dieser Reguläre Ausdruck meint alle dreistelligen Zahlen von 100 bis 999

Fehlertext

Die DIN 277 <Wert> entspricht nicht der geforderten Schreibweise.

Richtig wäre eine dreistellige Zahl, die keine führende Null haben darf.

X61.6 <CatalogReference> Attribut IDRef für CatalogType=“DIN DIN 277-2″

Wenn das Attribut Alias von <CatalogReference> mit dem Attribut Alias von einem Element <CatalogDescription>

mit dem Attribut CatalogType=“DIN 277-2″ übereinstimmt, dann muss der Wert im Attribut IDRef

des Elementes <CatalogReference> dem folgenden Regulären Ausdruck entsprechen:

[1-9](\.\d)?

Dieser Ausdruck meint eine Ziffer optional gefolgt von einem Punk und einer weiteren Ziffer

Fehlertext

Die DIN 277 <Wert> entspricht nicht der geforderten Schreibweise. Richtig wäre eine Ziffer,

der ggf. ein Punkt und eine weitere Ziffer folgt.

X61.7 <CatalogReference> Attribut IDRef für CatalogType=“Z-Artikel“

Wenn das Attribut Alias von <CatalogReference> mit dem Attribut Alias von einem

Element <CatalogDescription> mit dem Attribut CatalogType=“Z-Artikel“ übereinstimmt,

dann muss der Wert im Attribut IDRef des Elementes <CatalogReference> dem folgenden

Regulären Ausdruck entsprechen:

Z(\.[A-Za-z]*[A-Za-z0-9][0-9]*){2,5}

Dieser Ausdruck meint z.B. Z.G3.34.5.23.101

Fehlertext

Der Verweis auf Z-Artikel <Wert> entspricht nicht der geforderten Schreibweise.

Richtig wäre z.B. Z.G3.34.5.23.101

X61.8 <CatalogReference> Attribut IDRef für CatalogType=“Z-Merkmal“

Wenn das Attribut Alias von <CatalogReference> mit dem Attribut Alias von einem

Element <CatalogDescription> mit dem Attribut CatalogType=“Z-Merkmal“ übereinstimmt,

dann muss der Wert im Attribut IDRef des Elementes <CatalogReference>

dem folgenden Regulären Ausdruck entsprechen:

Z[A-Z]{0,2}\d{0,3}(\.[A-Za-z]*[A-Za-z0-9][0-9]*){1,3}

Dieser Ausdruck meint z.B.

    ZR.14.2.102,

    Z.L0002,

    ZA003.1.109

Fehlertext

Der Verweis auf Z-Merkmal <Wert> entspricht nicht der geforderten Schreibweise.

Richtig wäre z.B. ZR.14.2.102, Z.L0002, ZA003.1.109

X61.9 <CatalogReference> Attribut IDRef für CatalogType=“STLB-Bau“

Wenn das Attribut Alias von <CatalogReference> mit dem Attribut Alias von einem

Element <CatalogDescription> mit dem Attribut CatalogType=“STLB-Bau“ übereinstimmt,

dann muss der Wert im Attribut IDRef des Elementes <CatalogReference>

dem folgenden Regulären Ausdruck entsprechen:

~G\d+|~P\d+(V\d+)?|QU|UP

Fehlertext

Der Verweis auf STLB-Bau <Wert> entspricht nicht der geforderten Schreibweise.

X61.10 <CatalogReference> Attribut IDRef für CatalogType=“DBD-KE „

Wenn das Attribut Alias von <CatalogReference> mit dem Attribut Alias von einem

Element <CatalogDescription> mit dem Attribut CatalogType=“DBD-KE “ übereinstimmt,

dann muss der Wert im Attribut IDRef des Elementes <CatalogReference>

dem folgenden Regulären Ausdruck entsprechen:

~G\d+|~P\d+(V\d+)?|[A-Za-z_][A-Za-z0-9_]*

Fehlertext

Der Verweis auf DBD-KE <Wert> entspricht nicht der geforderten Schreibweise.

Downloads finden sie im Downloadbereich

X80 Änderungen gegen BetaV3.2-1

QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

X81 Änderungen gegen BetaV3.2-1

QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

X82 Änderungen gegen BetaV3.2-1

QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

X83 Änderungen gegen BetaV3.2-1

QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

X84 Änderungen gegen BetaV3.2-1

• Pre und Post BoQText gelöscht
• QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

X85 Änderungen gegen BetaV3.2-1

QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

86 Änderungen gegen BetaV3.2-1

QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

X87 Änderungen gegen BetaV3.2-1

QtyDeterm (Mengenermittlung) in tgItem aktiviert

Downloads finden sie im Downloadbereich

X89 Änderungen gegen BetaV3.2-1

die Datenaustauschphase 89-Rechnung fehlte in der Beta-Version 3.2-1 noch

Downloads finden sie im Downloadbereich