Updated EFAPI definition for x64 GCC. Original thinking was to add optional EFIAPI...
[mirror_edk2.git] / Tools / XMLSchema / FarManifest.xsd
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!--
3 Filename: FarManifest.xsd
5 Copyright (c) 2006, Intel Corp.
6 All rights reserved. This program and the accompanying materials
7 are licensed and made available under the terms and conditions of the BSD License
8 which may be found at http://opensource.org/licenses/bsd-license.php
13 -->
14 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://www.TianoCore.org/2006/Edk2.0" xmlns="http://www.TianoCore.org/2006/Edk2.0">
15 <xs:include schemaLocation="FrameworkHeaders.xsd"/>
16 <xs:annotation>
17 <xs:documentation xml:lang="en">
18 The Framework Archive File Format is defined as a Java Archive file, with a special xml file called FrameworkArchiveManifest.xml at the top of the archive. The FrameworkArchiveManifest.xml must be an instance of this schema.
19 </xs:documentation>
20 </xs:annotation>
21 <xs:element name="FrameworkArchiveManifest">
22 <xs:annotation>
23 <xs:documentation xml:lang="en">
24 This schema defines the Framework Archive Manifest.
25 </xs:documentation>
26 </xs:annotation>
27 <xs:complexType>
28 <xs:sequence>
29 <xs:element minOccurs="1" maxOccurs="1" ref="FarHeader"/>
30 <xs:element minOccurs="0" maxOccurs="1" ref="FarPackageList">
31 <xs:annotation>
32 <xs:documentation>
33 The list of packages in this FAR.
34 </xs:documentation>
35 </xs:annotation>
36 </xs:element>
37 <xs:element minOccurs="0" maxOccurs="1" ref="FarPlatformList">
38 <xs:annotation>
39 <xs:documentation>
40 The list of platforms in this FAR.
41 </xs:documentation>
42 </xs:annotation>
43 </xs:element>
44 <xs:element minOccurs="0" maxOccurs="1" ref="Contents">
45 <xs:annotation>
46 <xs:documentation>
47 Extra contents that are not part of any Package or Platform. These file paths are WORKSPACE relative. If a file exists in the workspace at this location, then the user should be asked whether to overwrite. When the user removes the far, these should be removed also, unless they have been modified (per md5sum).
48 </xs:documentation>
49 </xs:annotation>
50 </xs:element>
51 <xs:element minOccurs="0" maxOccurs="unbounded" ref="UserExtensions"/>
52 </xs:sequence>
53 </xs:complexType>
54 </xs:element>
55 <xs:element name="FarPackageList">
56 <xs:complexType>
57 <xs:sequence>
58 <xs:element minOccurs="1" maxOccurs="unbounded" ref="FarPackage"/>
59 </xs:sequence>
60 </xs:complexType>
61 </xs:element>
62 <xs:element name="FarPackage">
63 <xs:complexType>
64 <xs:sequence>
65 <xs:element ref="FarFilename">
66 <xs:annotation>
67 <xs:documentation>
68 This is the name of the .spd or file that describes the package. It must exist in the directory identified by DefaultPath.
69 </xs:documentation>
70 </xs:annotation>
71 </xs:element>
72 <xs:element ref="GuidValue"></xs:element>
73 <xs:element ref="Version"></xs:element>
74 <xs:element ref="DefaultPath">
75 <xs:annotation>
76 <xs:documentation>
77 This is the default installation location within the workspace. This also serves as the location within the far itself of the package root. The Contents of the pacakage will be found there. The user may choose some other location within the workspace to install the package, as long as it does not overlap a package that is already installed.
78 </xs:documentation>
79 </xs:annotation>
80 </xs:element>
81 <xs:element minOccurs="0" maxOccurs="1" ref="FarPlatformList">
82 <xs:annotation>
83 <xs:documentation>
84 This list of platforms is relative to the package root of the package that they are contained in. If the package that these are bound to is intstalled in some directory other than the default, then these platforms should be stored relative to that.
85 </xs:documentation>
86 </xs:annotation>
87 </xs:element>
88 <xs:element ref="Contents">
89 <xs:annotation>
90 <xs:documentation>
91 This is the list of files that belong to the package. They are specified by relative path from the root of the pacakge.
92 </xs:documentation>
93 </xs:annotation>
94 </xs:element>
95 <xs:element minOccurs="0" maxOccurs="unbounded" ref="UserExtensions"></xs:element>
96 </xs:sequence>
97 </xs:complexType>
98 </xs:element>
99 <xs:element name="FarPlatform">
100 <xs:annotation>
101 <xs:documentation>
102 Platforms are treated separately from packages. A platform is listed in the far if, and only if, it is not part of some package.
103 </xs:documentation>
104 </xs:annotation>
105 <xs:complexType>
106 <xs:sequence>
107 <xs:element ref="FarFilename">
108 <xs:annotation>
109 <xs:documentation>
110 This is the relative path to the .fpd file that describes the platform.
111 </xs:documentation>
112 </xs:annotation>
113 </xs:element>
114 <xs:element ref="GuidValue"></xs:element>
115 <xs:element ref="Version"></xs:element>
116 <xs:element minOccurs="0" maxOccurs="unbounded" ref="UserExtensions"></xs:element>
117 </xs:sequence>
118 </xs:complexType>
119 </xs:element>
120 <xs:element name="DefaultPath" type="PathAndFilename"/>
121 <xs:element name="FarPlatformList">
122 <xs:complexType>
123 <xs:sequence>
124 <xs:element maxOccurs="unbounded" ref="FarPlatform">
125 </xs:element>
126 </xs:sequence>
127 </xs:complexType>
128 </xs:element>
129 <xs:element name="FarFilename" type="DbPathAndFilename">
130 <xs:annotation>
131 <xs:documentation>
132 The FarFilename is used to build up the Contents list. It has an md5sum attribute for keeping track of whether the file is changed after it is installed. The Md5sum can also be used to check the integrity of a far before it is installed into the workspace.
133 </xs:documentation>
134 </xs:annotation>
135 </xs:element>
136 <xs:element name="GuidValue" type="GuidType">
137 <xs:annotation>
138 <xs:documentation>
139 The purpose of this element is to allow Guids to be assigned to or used by other elements in the schema.
140 </xs:documentation>
141 </xs:annotation>
142 </xs:element>
143 <xs:element name="Contents">
144 <xs:annotation>
145 <xs:documentation>
146 This tag allows us to specify a tree of files all having a common root. All the files specified are relative to that common root.
147 </xs:documentation>
148 </xs:annotation>
149 <xs:complexType>
150 <xs:sequence>
151 <xs:element maxOccurs="unbounded" ref="FarFilename"/>
152 </xs:sequence>
153 </xs:complexType>
154 </xs:element>
155 <xs:annotation>
156 <xs:documentation xml:lang="en">
157 Definitions and rules for creating, installing, updating and removing fars within the workspace.
158 </xs:documentation>
159 <xs:documentation>
160 1. A module m is said to depend upon a package p, iff there exists a tuple (PackageGuid, PackageVerion) in the set m->PackageDependencies for which p->Guid==PackageGuid, and if PackageVersion is not empty, then p->Version== PackageVersion.
161 </xs:documentation>
162 <xs:documentation>
163 2. A far f is said to depend on a far g, iff there is a module in a package in f that depends on a package in g.
164 </xs:documentation>
165 <xs:documentation>
166 3. A far f is said to depend on a package p, iff there is a module m contained in f that depends on p.
167 </xs:documentation>
168 <xs:documentation>
169 3.1 A platform q is said to depend on a package p, iff p, or some module m contained in p, is necessary to build q.
170 </xs:documentation>
171 <xs:documentation>
172 4. A far f may be installed into the workspace w, iff for each module m in f, m’s dependencies are met by the packages in w.
173 </xs:documentation>
174 <xs:documentation>
175 a. (If the dependencies are not met, then no part of far f will be installed. It is not legal to partially install a far into the workspace.)
176 </xs:documentation>
177 <xs:documentation>
178 5. A far f may be removed from the workspace w, iff for each module m in w, and for each package p in f, m does not depend on p.
179 </xs:documentation>
180 <xs:documentation>
181 a. (If there is some dependency on f, then no part of f may be uninstalled from w. It is not legal to partially uninstall a far from the workspace.)
182 </xs:documentation>
183 <xs:documentation>
184 6. When installing a far f into workspace w, for each package p in f, allow the user to install in p's default location, or choose a new location l (which must be unoccupied) within the workspace. Record this location l in the database. Each package p in f will be recorded in the database, associated with the GUID of f, as well as the actual install location l. (So we will know which far each package belongs to.)
185 </xs:documentation>
186 <xs:documentation>
187 7. When installing a far f into workspace w, if there exists a package p in w, and p is in f, then the user must be prompted to choose a location that does not collide with the location of p in workspace w. We will end up with two instances of p in w at two distinct locations.
188 </xs:documentation>
189 <xs:documentation>
190 8. A far f may replace a far g in the workspace w, iff for each module m contained in w, if m depends on a package p, and p is only contained in g, then there must exist a package q in f, such that m depends on q. The net effect is that g is removed and f is installed, in one operation. The normal rules for installing f still apply--the dependencies of the modules of f must be satisfied. After the replacement, it must be the case that all the modules dependencies in the workspace are satisfied. Note that it is possible to backrev a package in this way.
191 </xs:documentation>
192 <xs:documentation>
193 (If we find that the replace is not permitted, then the user may install f and keep g. Next, he could _port_ every module m in w that depends on g, to f and eventually remove g.)
194 </xs:documentation>
195 <xs:documentation>
196 9. A special case of the above rule is that a far f may be reinstalled into the workspace. (This would allow the user to get a fresh copy, or change the location in the workspace where one or more of the packages of f are installed.)
197 </xs:documentation>
198 <xs:documentation>
199 10. When a far f is removed from the workspace w, for each package p in f, we will remove p from w.
200 </xs:documentation>
201 <xs:documentation>
202 11. If a package p belongs to a far f, then it is not legal to remove p from the workspace w unless f is removed from w.
203 </xs:documentation>
204 <xs:documentation>
205 11.1 If a platform p belongs to a far f, then it is not legal to remove p from the workspace w unless f is removed from w.
206 </xs:documentation>
207 <xs:documentation>
208 12. A package p may be removed from the workspace, provided there does not exist a far f that contains p. (Newly created or cloned packages will not exist within a far, and thus may be removed from the workspace directly.)
209 </xs:documentation>
210 <xs:documentation>
211 13. When a far f is removed from the workspace, the we will remove all the files in f from the workspace tree. If a file has been modified from the original as installed from the far (per md5sum) then the user should be asked if he is "sure" he wants to remove it.
212 </xs:documentation>
213 <xs:documentation>
214 14. When a far is created, a GUID is generated and assigned to the far. If a far is created from the same components at a later time, it would have a different GUID.
215 </xs:documentation>
216 <xs:documentation>
217 15. If a package p is marked with p->RePackage==false, then p may not be added to a far.
218 </xs:documentation>
219 <xs:documentation>
220 16. When constructing a far f that contains at least one platform, then f may optionally be constructed such that for each platform q in f, every package p on which q depends should be included in f, unless p->RePackage==false. The far will have all the packages required, and may then be installed as a self-inflating executable that will create a brand new workspace on the developer's workstation.
221 </xs:documentation>
222 <xs:documentation>
223 17. A far f is identical to a far g, iff f->Guid == g->Guid.
224 </xs:documentation>
225 <xs:documentation>
226 18. A far f may be installed into the workspace w, iff there is no far g in w such that f->Guid==g->Guid.
227 </xs:documentation>
228 </xs:annotation>
229 </xs:schema>