Adding BaseTools directory structure for the new generation of EDK II Builds.
[mirror_edk2.git] / BaseTools / Conf / XMLSchema / FarManifest.xsd
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!--
3 Filename: FarManifest.xsd
5 Copyright (c) 2007, 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
13 -->
14 <xs:schema xmlns:xs="" elementFormDefault="qualified" targetNamespace="" xmlns="">
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="Contents">
38 <xs:annotation>
39 <xs:documentation>
40 Extra contents that are not part of any Package. 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).
41 </xs:documentation>
42 </xs:annotation>
43 </xs:element>
44 <xs:element minOccurs="0" maxOccurs="unbounded" ref="UserExtensions"/>
45 </xs:sequence>
46 </xs:complexType>
47 </xs:element>
48 <xs:element name="FarPackageList">
49 <xs:complexType>
50 <xs:sequence>
51 <xs:element minOccurs="1" maxOccurs="unbounded" ref="FarPackage"/>
52 </xs:sequence>
53 </xs:complexType>
54 </xs:element>
55 <xs:element name="FarPackage">
56 <xs:complexType>
57 <xs:sequence>
58 <xs:element ref="FarFilename">
59 <xs:annotation>
60 <xs:documentation>
61 This is the name of the .spd or file that describes the package. It must exist in the directory identified by DefaultPath.
62 </xs:documentation>
63 </xs:annotation>
64 </xs:element>
65 <xs:element ref="GuidValue"></xs:element>
66 <xs:element ref="Version"></xs:element>
67 <xs:element ref="DefaultPath">
68 <xs:annotation>
69 <xs:documentation>
70 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.
71 </xs:documentation>
72 </xs:annotation>
73 </xs:element>
74 <xs:element ref="Contents">
75 <xs:annotation>
76 <xs:documentation>
77 This is the list of files that belong to the package. They are specified by relative path from the root of the pacakge.
78 </xs:documentation>
79 </xs:annotation>
80 </xs:element>
81 <xs:element minOccurs="0" maxOccurs="unbounded" ref="UserExtensions"></xs:element>
82 </xs:sequence>
83 </xs:complexType>
84 </xs:element>
85 <xs:element name="DefaultPath" type="PathAndFilename"/>
86 <xs:element name="FarFilename" type="DbPathAndFilename">
87 <xs:annotation>
88 <xs:documentation>
89 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.
90 </xs:documentation>
91 </xs:annotation>
92 </xs:element>
93 <xs:element name="GuidValue" type="GuidType">
94 <xs:annotation>
95 <xs:documentation>
96 The purpose of this element is to allow Guids to be assigned to or used by other elements in the schema.
97 </xs:documentation>
98 </xs:annotation>
99 </xs:element>
100 <xs:element name="Contents">
101 <xs:annotation>
102 <xs:documentation>
103 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.
104 </xs:documentation>
105 </xs:annotation>
106 <xs:complexType>
107 <xs:sequence>
108 <xs:element maxOccurs="unbounded" ref="FarFilename"/>
109 </xs:sequence>
110 </xs:complexType>
111 </xs:element>
112 <xs:annotation>
113 <xs:documentation xml:lang="en">
114 Definitions and rules for creating, installing, updating and removing fars within the workspace.
115 </xs:documentation>
116 <xs:documentation>
117 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.
118 </xs:documentation>
119 <xs:documentation>
120 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.
121 </xs:documentation>
122 <xs:documentation>
123 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.
124 </xs:documentation>
125 <xs:documentation>
126 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 or f.
127 </xs:documentation>
128 <xs:documentation>
129 a. It is supported to "partially" install a far. A partial installation of a far means that 1 or more packages are installed into the workspace from the far. For each package p in f, p's dependencies must be satisfied by a package in the workspace.
130 </xs:documentation>
131 <xs:documentation>
132 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.
133 </xs:documentation>
134 <xs:documentation>
135 a. It is supported to "partially" remove a far. In this case, one or more of the packages in the far can be removed, provided that for each package p in the workspace w, there does not exist a module m such that m depends on p.
136 </xs:documentation>
137 <xs:documentation>
138 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.)
139 </xs:documentation>
140 <xs:documentation>
141 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. Alternately, the user may elect to partially install the far, leaving out the redundant package.
142 </xs:documentation>
143 <xs:documentation>
144 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.
145 </xs:documentation>
146 <xs:documentation>
147 (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.)
148 </xs:documentation>
149 <xs:documentation>
150 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.)
151 </xs:documentation>
152 <xs:documentation>
153 10. When a far f is removed from the workspace w, for each package p in f, we will remove p from w.
154 </xs:documentation>
155 <xs:documentation>
156 11. If a package p belongs to a far f, then it is legal to remove p from the workspace w iff, there does not exist a module m in w such that m depends on p.
157 </xs:documentation>
158 <xs:documentation>
159 12. 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.
160 </xs:documentation>
161 <xs:documentation>
162 13. 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.
163 </xs:documentation>
164 <xs:documentation>
165 14. If a package p is marked with p->RePackage==false, then p may not be added to a far.
166 </xs:documentation>
167 <xs:documentation>
168 15. A far f is identical to a far g, iff f->Guid == g->Guid.
169 </xs:documentation>
170 <xs:documentation>
171 17. A far f may be installed into the workspace w, iff there is no far g in w such that f->Guid==g->Guid. In that case, it is called "updating" the far in the workspace. The user may select some subset of packages to reinstall or update, to ensure that the files in the workspace are correct.
172 </xs:documentation>
173 </xs:annotation>
174 </xs:schema>