aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/OpenSim/ApplicationPlugins/Rest/rest.xsd
diff options
context:
space:
mode:
authorDr Scofield2008-09-18 15:50:52 +0000
committerDr Scofield2008-09-18 15:50:52 +0000
commiteeb5381bbbf58190824d047d845569564368c708 (patch)
treec2bf745ae3246339c0bfaf7e0be3f5144c8806a6 /OpenSim/ApplicationPlugins/Rest/rest.xsd
parentAdds REST interface for setting avatar appearance. cleans up a couple (diff)
downloadopensim-SC-eeb5381bbbf58190824d047d845569564368c708.zip
opensim-SC-eeb5381bbbf58190824d047d845569564368c708.tar.gz
opensim-SC-eeb5381bbbf58190824d047d845569564368c708.tar.bz2
opensim-SC-eeb5381bbbf58190824d047d845569564368c708.tar.xz
and this actually adds the appearance code itself (and not just the
check-in message)
Diffstat (limited to '')
-rw-r--r--OpenSim/ApplicationPlugins/Rest/rest.xsd276
1 files changed, 276 insertions, 0 deletions
diff --git a/OpenSim/ApplicationPlugins/Rest/rest.xsd b/OpenSim/ApplicationPlugins/Rest/rest.xsd
new file mode 100644
index 0000000..4dc0ae4
--- /dev/null
+++ b/OpenSim/ApplicationPlugins/Rest/rest.xsd
@@ -0,0 +1,276 @@
1<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
2
3 <xsd:annotation>
4 <xsd:documentation xml:lang="en">
5 Open Simulator Export/Import XML schema
6 August 2008
7 </xsd:documentation>
8 </xsd:annotation>
9
10 <!-- WARNING!!!
11 This is currently a draft, it does not reflect
12 what is exported, nor what will be understood
13 on import. It is included as a working document
14 and this comment will be removed at such time as
15 the schema corresponds to reality.
16 -->
17
18 <!--
19 REST-related information
20 Inventory data is always framed by an
21 inventory element. Consists of zero or
22 more elements representing either folders
23 or items within those folders. The inventory
24 element represents the "real" root folder.
25 -->
26
27 <xsd:element name="inventory" type="inventory_ct" />
28
29 <!--
30 The inventory complex type is just an arbitrary
31 sequence of folders and items. In reality it is
32 typically just folders. Both item and folder
33 have corresponding complex types. It is distinct
34 from folders insofar as it has no other defining
35 attributes.
36 -->
37
38 <xsd:complexType name="inventory_ct">
39 <xsd:element name="folder" type="folder_ct" maxOccurs="unbounded"/>
40 <xsd:element name="item" type="item_ct" maxOccurs="unbounded" />
41 </xsd:complexType>
42
43 <xsd:complexType name="folder_ct">
44 <xsd:attribute name="UUID" type="uuid_st" />
45 <xsd:attribute name="name" type="name_st" />
46 <xsd:attribute name="type" type="folder_type_st" />
47 <xsd:attribute name="description" type="xsd:string" /> <!-- added -->
48 <xsd:attribute name="version" type="unsignedShort" />
49 <xsd:attribute name="owner" type="uuid_st" />
50
51 <xsd:attribute name="creator" type="uuid_st" /> <!-- added -->
52 <xsd:attribute name="creationdate" type="date_st" /> <!-- added -->
53
54 <xsd:attribute name="parent" type="uuid_st" />
55
56 <xsd:element name="permissions" type="permissions_ct" maxOccurs="unbounded" /> <!-- added -->
57 <xsd:element name="folder" type="folder_ct" maxOccurs="unbounded" />
58 <xsd:element name="item" type="item_ct" maxOccurs="unbounded" />
59 </xsd:complexType>
60
61 <xsd:complexType name="item_ct">
62 <xsd:attribute name="UUID" type="uuid_st" />
63 <xsd:attribute name="name" type="name_st" />
64 <xsd:attribute name="type" type="inventory_type_st" />
65 <xsd:attribute name="description" type="xsd:string" />
66 <xsd:attribute name="version" type="unsignedShort" /> <!-- added -->
67 <xsd:attribute name="owner" type="uuid_st" />
68
69 <xsd:attribute name="creator" type="uuid_st" />
70 <xsd:attribute name="creationdate" type="date_st" />
71
72 <xsd:attribute name="folder" type="uuid_st" />
73 <xsd:attribute name="groupid" type="uuid_st" />
74 <xsd:attribute name="groupowned" type="xsd:boolean" />
75 <xsd:attribute name="saletype" type="sale_st" />
76 <xsd:attribute name="saleprice" type="xsd:decimal" />
77
78 <xsd:element name="permissions" type="permissions_ct" maxOccurs="unbounded" />
79 </xsd:complexType>
80
81 <xsd:complexType name="asset_ct">
82 <xsd:attribute name="UUID" type="uuid_st" />
83 <xsd:attribute name="name" type="name_st" />
84 <xsd:attribute name="type" type="asset_type_st" />
85 <xsd:attribute name="description" type="xsd:string" />
86 <xsd:attribute name="version" type="unsignedShort" /> <!-- added -->
87 <xsd:attribute name="owner" type="uuid_st" />
88
89 <xsd:attribute name="creator" type="uuid_st" />
90 <xsd:attribute name="creationdate" type="date_st" />
91
92 <xsd:attribute name="temporary" type="xsd:boolean" />
93 <xsd:attribute name="local" type="xsd:boolean" />
94 <xsd:attribute name="inline" type="xsd:boolean" />
95 </xsd:complexType>
96
97 <!-- Constrained Simple Data types -->
98
99 <!--
100 We need to specify name as a simple type because on
101 some platforms it is constrained by a certain length
102 limitation. For completeness we indicate that whitespace
103 should be preserved exactly as specified.
104 -->
105
106 <xsd:simpleType name="name_st">
107 <xsd:restriction base="xsd:string">
108 <whiteSpace value="preserve" />
109 <minLength value="0" />
110 <maxLength value="64" />
111 </xsd:restriction>
112 </xsd:simpleType>
113
114 <!--
115 Type information in the folder is meant to indicate
116 the preferred asset type for this folder. As such, that
117 currently corresponds to the type values allowed for
118 assets, however that is not mandated, so for
119 now at least I'll represent this as a distinct
120 enumeration.
121 This seems inappropriate; it seems like the folder's
122 content should reflect the InventoryType classifications
123 rather than the asset types.
124 -->
125
126 <xsd:simpleType name="folder_type_st">
127 <xsd:restriction base="xsd:string">
128 <xsd:enumeration value="Texture" />
129 <xsd:enumeration value="Sound" />
130 <xsd:enumeration value="CallingCard" />
131 <xsd:enumeration value="Landmark" />
132 <xsd:enumeration value="Script" />
133 <xsd:enumeration value="Clothing" />
134 <xsd:enumeration value="Object" />
135 <xsd:enumeration value="Notecard" />
136 <xsd:enumeration value="LSLText" />
137 <xsd:enumeration value="LSLByteCode" />
138 <xsd:enumeration value="TextureTGA" />
139 <xsd:enumeration value="BodyPart" />
140 <xsd:enumeration value="SoundWAV" />
141 <xsd:enumeration value="ImageTGA" />
142 <xsd:enumeration value="ImageJPEG" />
143 <xsd:enumeration value="Animation" />
144 <xsd:enumeration value="Gesture" />
145 <xsd:enumeration value="Simstate" />
146 <xsd:enumeration value="Unknown" />
147 <xsd:enumeration value="LostAndFoundFolder" />
148 <xsd:enumeration value="SnapshotFolder" />
149 <xsd:enumeration value="TrashFolder" />
150 <xsd:enumeration value="Folder" />
151 <xsd:enumeration value="RootFolder" />
152 </xsd:restriction>
153 </xsd:simpleType>
154
155 <!--
156 Inventory item type designates an asset class, rather
157 than a specific asset type. For example, "SnapShot"
158 might include a number of asset types such as JPEG,
159 TGA, etc.. This is not a consistent interpretation,
160 classifications such as LostAndFound are meta-types
161 relative to asset classes.
162
163 These types should be abstract and not be tied to a
164 specific platform. A world's import facility should be
165 responsible for mapping these to meaningful internal
166 representations.
167
168 These types were based on information in:
169 libsecondlife/InventoryManager.cs
170 -->
171
172 <xsd:simpleType name="inventory_type_st">
173 <xsd:restriction base="xsd:string">
174 <xsd:enumeration value="Texture" />
175 <xsd:enumeration value="Sound" />
176 <xsd:enumeration value="CallingCard" />
177 <xsd:enumeration value="Landmark" />
178 <xsd:enumeration value="Script" />
179 <xsd:enumeration value="Clothing" />
180 <xsd:enumeration value="Object" />
181 <xsd:enumeration value="Notecard" />
182 <xsd:enumeration value="LSL" />
183 <xsd:enumeration value="LSLBytecode" />
184 <xsd:enumeration value="TextureTGA" />
185 <xsd:enumeration value="BodyPart" />
186 <xsd:enumeration value="Snapshot" />
187 <xsd:enumeration value="Attachment" />
188 <xsd:enumeration value="Wearable" />
189 <xsd:enumeration value="Animation" />
190 <xsd:enumeration value="Gesture" />
191 <xsd:enumeration value="Folder" />
192 <xsd:enumeration value="Unknown" />
193 <xsd:enumeration value="LostAndFound" />
194 <xsd:enumeration value="Trash" />
195 <xsd:enumeration value="Root" />
196 </xsd:restriction>
197 </xsd:simpleType>
198
199 <!--
200 The asset types seem to be even more disarrayed than
201 the inventory types. It seems to be little more than
202 a reiteration of the inventory type information,
203 which adds little or nothing to the overall data
204 model.
205
206 Of course, given that these are drawn from the
207 libsecondlife definitions, we aren't at liberty to
208 simply redefine them in place. But the XML definitions
209 here could be made more useful.
210
211 These types were based on information in:
212 libsecondlife/AssetManager.cs
213 -->
214
215 <xsd:simpleType name="asset_type_st">
216 <xsd:restriction base="xsd:string">
217 <xsd:enumeration value="Texture" />
218 <xsd:enumeration value="Sound" />
219 <xsd:enumeration value="CallingCard" />
220 <xsd:enumeration value="Landmark" />
221 <xsd:enumeration value="Script" />
222 <xsd:enumeration value="Clothing" />
223 <xsd:enumeration value="Object" />
224 <xsd:enumeration value="Notecard" />
225 <xsd:enumeration value="LSLText" />
226 <xsd:enumeration value="LSLByteCode" />
227 <xsd:enumeration value="TextureTGA" />
228 <xsd:enumeration value="BodyPart" />
229 <xsd:enumeration value="SoundWAV" />
230 <xsd:enumeration value="ImageTGA" />
231 <xsd:enumeration value="ImageJPEG" />
232 <xsd:enumeration value="Animation" />
233 <xsd:enumeration value="Gesture" />
234 <xsd:enumeration value="Simstate" />
235 <xsd:enumeration value="Unknown" />
236 <xsd:enumeration value="LostAndFoundFolder" />
237 <xsd:enumeration value="SnapshotFolder" />
238 <xsd:enumeration value="TrashFolder" />
239 <xsd:enumeration value="Folder" />
240 <xsd:enumeration value="RootFolder" />
241 </xsd:restriction>
242 </xsd:simpleType>
243
244 <!-- This is describing the apparent form of a UUID. If
245 we ever want a more metaphysical definition we'll
246 need to add to it.
247 -->
248
249 <xsd:simpleType name="uuid_st">
250 <xsd:restriction base="xsd:string">
251 <xsd:pattern value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}"/>
252 </xsd:restriction>
253 </xsd:simpleType>
254
255 <!-- This constrains the date representation. Currently
256 it is simply an integer representing the elapsed
257 ?? since ??.
258 -->
259
260 <xsd:simpleType name="date_st">
261 <xsd:restriction base="xsd:positiveInteger">
262 </xsd:restriction>
263 </xsd:simpleType>
264
265 <!-- This constrains the representation of sale price.
266 Currently it is a simple decimal with no unit
267 specified.
268 Issues: interoperability.
269 -->
270
271 <xsd:simpleType name="sale_st">
272 <xsd:restriction base="xsd:decimal">
273 </xsd:restriction>
274 </xsd:simpleType>
275
276</xsd:schema>
generated by cgit v1.1 at 2024-11-20 17:22:31 +0000