/[volute]/trunk/projects/dm/vo-dml/xsd/vo-dml-v1.0.xsd
ViewVC logotype

Contents of /trunk/projects/dm/vo-dml/xsd/vo-dml-v1.0.xsd

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3038 - (show annotations)
Tue Aug 25 14:27:31 2015 UTC (5 years, 11 months ago) by gerard.lemson
File size: 43177 byte(s)
updating vo-dml XSD products.
1 <?xml version="1.0" encoding="UTF-8"?>
2 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
3 xmlns="http://volute.googlecode.com/dm/vo-dml/v0.9"
4 targetNamespace="http://volute.googlecode.com/dm/vo-dml/v0.9"
5 attributeFormDefault="unqualified" elementFormDefault="unqualified">
6
7 <xsd:annotation>
8 <xsd:documentation>
9
10 This schema defines the "vo-dml meta model", a modeling language used to define the concepts
11 and structures that describe data models. It is proposed as the common language for
12 defining data models in the IVOA.
13 TBD continue based on VO-DML specification document.
14 </xsd:documentation>
15 <xsd:documentation>
16 Look at SVN versions 2129 and earlier for more extensive model.
17 </xsd:documentation>
18 </xsd:annotation>
19
20 <!-- +++++++++++++++++++ Begin of 'Identifier section' +++++++++++++++++++ -->
21 <xsd:simpleType name="VODMLID" >
22 <xsd:annotation>
23 <xsd:documentation>
24 Type representing the way referable elements are identified uniquely in VO-DML.
25 </xsd:documentation>
26 </xsd:annotation>
27 <xsd:restriction base="xsd:string">
28 <xsd:annotation>
29 <xsd:documentation>
30 A restriction on the valid strings that make this a VO-DML Identifier.
31 Requirements on the format are: 1) use in XML document 2) use as fragment in URI
32 </xsd:documentation>
33 </xsd:annotation>
34 <xsd:pattern value="[\w\._-]+"/>
35 </xsd:restriction>
36 </xsd:simpleType>
37
38 <xsd:simpleType name="ModelName">
39 <xsd:annotation>
40 <xsd:documentation>
41 Type used to restrict valid values for prefixes.
42 TBD We could use an xsd:NCName for this.
43 </xsd:documentation>
44 </xsd:annotation>
45 <xsd:restriction base="xsd:string"> <!-- xsd:NCName ? -->
46 <xsd:pattern value="[\w_-]+">
47 <xsd:annotation>
48 <xsd:documentation>
49 A model name MUST NOT contain a semicolon.
50 </xsd:documentation>
51 </xsd:annotation>
52 </xsd:pattern>
53 </xsd:restriction>
54 </xsd:simpleType>
55
56 <xsd:simpleType name="VODMLREF">
57 <xsd:annotation>
58 <xsd:documentation>
59 Class representing the way ReferencableElements can be referenced in VO-DML.
60 It must be possible to refer to elements in other, imported data models as well as in the current model.
61 Hence the VODMLREF must identify both model and element.
62 The element is identified by the VO-DML ID in the model, the model is identified using a
63 prefix that MUST correspond to the vodml-id element of the current or an imported model.
64 Note, references to element sin the current model MUST also have a prefix, there is no default model!
65 TBD We could use an xsd:QName where VODMLREF is used, but that may have somewhat more sever syntax constraints than desired.
66 </xsd:documentation>
67 </xsd:annotation>
68 <xsd:restriction base="xsd:string"> <!-- xsd:QName ? -->
69 <xsd:annotation>
70 <xsd:documentation>
71 A restriction on the valid strings that make this a valid reference to a referencable element.
72 Consists of a prefix that should follow the ModelPrefix restriction
73 and a identifier that should follow the ElementID restriction,
74 separated from each other by a colon.
75 </xsd:documentation>
76 <xsd:documentation>
77 TODO define the restriction pattern properly.
78 MUST be [Prefix ':' VODMLID].
79 </xsd:documentation>
80 </xsd:annotation>
81 <xsd:pattern value="[\w_-]+:[\w_\-/\./*]+"/>
82 </xsd:restriction>
83 </xsd:simpleType>
84
85 <xsd:simpleType name="VODMLName">
86 <xsd:annotation>
87 <xsd:documentation>
88 Type used to restrict valid values for prefixes.
89 TBD We could use an xsd:NCName for this.
90 </xsd:documentation>
91 </xsd:annotation>
92 <xsd:restriction base="xsd:string"> <!-- xsd:NCName ? -->
93 <xsd:pattern value="[a-zA-Z_][\w_]*">
94 <xsd:annotation>
95 <xsd:documentation>
96 A model name MUST NOT contain a semicolon.
97 </xsd:documentation>
98 </xsd:annotation>
99 </xsd:pattern>
100 </xsd:restriction>
101 </xsd:simpleType>
102
103
104 <xsd:complexType name="ReferableElement" abstract="true">
105 <xsd:annotation>
106 <xsd:documentation>
107 This is the base type for all types whose elements can be explicitly referenced.
108 To this end it has a 'vodml-id' element of type VODMLID that allows explicit and unique identification of
109 these elements within the context of the model.
110 Generally these are also elements that can be
111 represented explicitly in alternative serialisations of
112 a data model, such as a VOTable or a relational model.
113 These should use the value of the utype element to "point into a data model" and identify a
114 model element. VO-DML itself also has needs of pointing to other elements, sometimes in another model.
115 The VODMLREF type is used for such references, which will always be named 'vodml-ref'.
116 </xsd:documentation>
117 </xsd:annotation>
118 <xsd:sequence>
119 <xsd:element name="vodml-id" type="VODMLID" minOccurs="1">
120 <xsd:annotation>
121 <xsd:documentation>
122 Identifier for its containing element.
123 Extracted as a separate type so that we can easily adapt to a different identifier design.
124 </xsd:documentation>
125 </xsd:annotation>
126 </xsd:element>
127 <xsd:element name="name" type="VODMLName" minOccurs="1" >
128 <xsd:annotation>
129 <xsd:documentation>
130 The name of the model element.
131 MUST NOT be an empty string.
132 </xsd:documentation>
133 </xsd:annotation>
134 </xsd:element>
135 <xsd:element name="description" type="xsd:string" minOccurs="0">
136 <xsd:annotation>
137 <xsd:documentation>
138 Human readable description of the model element.
139 </xsd:documentation>
140 </xsd:annotation>
141 </xsd:element>
142 </xsd:sequence>
143
144 <xsd:attribute name="id" type="xsd:string" use="optional">
145 <xsd:annotation>
146 <xsd:documentation>
147 A referencable element may be given an @id attribute to reflect an identifier
148 defined in some source document form which a VO-DML model may have been derived.
149 </xsd:documentation>
150 </xsd:annotation>
151 </xsd:attribute>
152 </xsd:complexType>
153
154
155 <xsd:complexType name="ElementRef">
156 <xsd:annotation>
157 <xsd:documentation>
158 This type represents how to reference a ReferencableElement.
159 It can serve as base class to those types that explicitly reference another type, such as relations and roles.
160 It provides for a uniform way to represent the reference to
161 the target element using the 'utyperef' element.
162 An important design choice is that we wish to allow references to elements in remote models.
163 For that reasons we can not use an ID/IDREF or key/keyref pattern.
164 Instead we define various constraints on
165 this type and its usage in various contexts using
166 the Schematron file in vo-dml.sch.xml.
167 </xsd:documentation>
168 </xsd:annotation>
169 <xsd:sequence>
170 <xsd:element name="vodml-ref" type="VODMLREF">
171 <xsd:annotation>
172 <xsd:documentation>
173 The element identifying the referenced target element.
174 See the documentation for the VODMLREF type.
175 </xsd:documentation>
176 </xsd:annotation>
177 </xsd:element>
178 </xsd:sequence>
179 </xsd:complexType>
180
181
182 <!-- +++++++++++++++++++ End of 'ReferencableElement section' +++++++++++++++++++ -->
183
184 <!-- +++++++++++++++++++ Begin of Model elements section +++++++++++++++++++ -->
185 <xsd:complexType name="Model">
186 <xsd:annotation>
187 <xsd:documentation>
188 Represents a complete data model and is the type of the (single) declared root element for
189 VO-DML/XML representation documents.
190 </xsd:documentation>
191 </xsd:annotation>
192 <xsd:sequence>
193 <xsd:element name="name" type="ModelName" minOccurs="1" maxOccurs="1">
194 <xsd:annotation>
195 <xsd:documentation>
196 Short name of the model.
197 NOTE this name MUST be used as prefix in any utype reference to elements in this model.
198 </xsd:documentation>
199 </xsd:annotation>
200 </xsd:element>
201 <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1">
202 <xsd:annotation>
203 <xsd:documentation>
204 The description of the model.
205 </xsd:documentation>
206 </xsd:annotation>
207 </xsd:element>
208 <xsd:element name="title" type="xsd:string" minOccurs="1" maxOccurs="1">
209 <xsd:annotation>
210 <xsd:documentation>
211 The title of the model by which it is officially known.
212 </xsd:documentation>
213 </xsd:annotation>
214 </xsd:element>
215 <xsd:element name="author" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
216 <xsd:annotation>
217 <xsd:documentation>
218 List of authors of the model, only defined by name so far.
219 TBD could be expanded with email, affiliation and so on.
220 </xsd:documentation>
221 </xsd:annotation>
222 </xsd:element>
223 <xsd:element name="version" type="xsd:string" minOccurs="1">
224 <xsd:annotation>
225 <xsd:documentation>
226 Label giving the version of the model.
227 </xsd:documentation>
228 </xsd:annotation>
229 </xsd:element>
230 <xsd:element name="previousVersion" type="xsd:anyURI" minOccurs="0">
231 <xsd:annotation>
232 <xsd:documentation>
233 URI identifying a VO-DML model that is the version from which the current version of model is derived.
234 TBD could be an IVO Identifier once models get properly registered?
235 </xsd:documentation>
236 </xsd:annotation>
237 </xsd:element>
238 <xsd:element name="lastModified" type="xsd:dateTime">
239 <xsd:annotation>
240 <xsd:documentation>
241 Timestamp when the last change to the current model was made.
242 </xsd:documentation>
243 </xsd:annotation>
244 </xsd:element>
245 <xsd:element name="import" type="ModelImport" minOccurs="0" maxOccurs="unbounded">
246 <xsd:annotation>
247 <xsd:documentation>
248 An 'import' element indicates a dependency on an external, predefined VO-DML data model.
249 Types from that model may be used for referencing, extension and assignment to
250 attributes.
251 Types from the external model MUST NOT be used for
252 composition relationships.
253 'identification' relations to elements from that model may be used to indicate some kind of
254 equivalence between
255 elements in the current model and the external elements.
256 </xsd:documentation>
257 <xsd:documentation>
258 TBD We might require that every data model MUST include a version of the IVOA data model
259 to gain access to the standard
260 primitive types and some other types.
261 We may require that that standard model should be included *completely*,
262 i.e. including all its type definitions explicitly.
263 This would be similar to treating it as a UML Profile, rather than an import.
264 This would mean that the most common type assignments for attributes
265 can be checked within the model and not require
266 importing the remote model during validation.
267 </xsd:documentation>
268 </xsd:annotation>
269 </xsd:element>
270 <xsd:element name="primitiveType" type="PrimitiveType" minOccurs="0" maxOccurs="unbounded">
271 <xsd:annotation>
272 <xsd:documentation>
273 Collection of PrimitiveType definitions directly under the model, i.e. not contained in a
274 Package.
275 </xsd:documentation>
276 </xsd:annotation>
277 </xsd:element>
278 <xsd:element name="enumeration" type="Enumeration" minOccurs="0" maxOccurs="unbounded">
279 <xsd:annotation>
280 <xsd:documentation>
281 Collection of Enumeration definitions directly under the model, i.e. not contained in a Package.
282 </xsd:documentation>
283 </xsd:annotation>
284 </xsd:element>
285 <xsd:element name="dataType" type="DataType" minOccurs="0" maxOccurs="unbounded">
286 <xsd:annotation>
287 <xsd:documentation>
288 Collection of DataType definitions directly under the model, i.e. not contained in a Package.
289 </xsd:documentation>
290 </xsd:annotation>
291 </xsd:element>
292 <xsd:element name="objectType" type="ObjectType" minOccurs="0" maxOccurs="unbounded">
293 <xsd:annotation>
294 <xsd:documentation>
295 Collection of ObjectType definitions directly under the model, i.e. not contained in a Package.
296 </xsd:documentation>
297 </xsd:annotation>
298 </xsd:element>
299 <xsd:element name="package" type="Package" minOccurs="0" maxOccurs="unbounded">
300 <xsd:annotation>
301 <xsd:documentation>
302 The collection of packages which can contain further detailed name spacing to
303 the type definitions in the model.
304 </xsd:documentation>
305 </xsd:annotation>
306 </xsd:element>
307 </xsd:sequence>
308 </xsd:complexType>
309
310
311 <xsd:complexType name="ModelImport">
312 <xsd:annotation>
313 <xsd:documentation>
314 A "proxy" for an external model that is being used by the current model.
315 Defines the url where the VO-DML representation of that model can be retrieved, and
316 replicates its name that MUST be used when making references to
317 elements in that model using a VODMLREF element.
318 </xsd:documentation>
319 </xsd:annotation>
320 <xsd:sequence>
321 <xsd:element name="name" type="ModelName" minOccurs="1">
322 <xsd:annotation>
323 <xsd:documentation>
324 Name by which imported model is used in the current model and its documentation.
325 This name MUST be the same as the 'name' of the model definition in that remote document.
326 For all utypes pointing to elements in the imported model MUST use this name as prefix.
327 </xsd:documentation>
328 </xsd:annotation>
329 </xsd:element>
330 <xsd:element name="version" type="xsd:string" minOccurs="0">
331 <xsd:annotation>
332 <xsd:documentation>
333 Version of the imported model.
334 </xsd:documentation>
335 </xsd:annotation>
336 </xsd:element>
337 <xsd:element name="url" type="xsd:anyURI" minOccurs="1">
338 <xsd:annotation>
339 <xsd:documentation>
340 URL from which the VO-DML model document can be downloaded.
341 Note, could likely be done through a registry once ivoId is known.
342 TBD SHOULD this be a generic URI, or can we insits on URL?
343 </xsd:documentation>
344 </xsd:annotation>
345 </xsd:element>
346 <xsd:element name="documentationURL" type="xsd:anyURI" minOccurs="1">
347 <xsd:annotation>
348 <xsd:documentation>
349 URL where a documentation HTML file for the remote model can be downloaded.
350 This SHOULD be a document that contains anchors for each element thta has as name attribute the vodml-id of that element.
351 I.e. it is assumed that the
352 vodml-id-s of the imported types can be added onto this documentationURL
353 (should end with a #?) so that a direct link to the documentation for a referenced data model element can be found.
354 </xsd:documentation>
355 </xsd:annotation>
356 </xsd:element>
357 </xsd:sequence>
358 </xsd:complexType>
359
360
361 <xsd:complexType name="Package">
362 <xsd:annotation>
363 <xsd:documentation>
364 A Package is a container for type definitions and possible (child-)packages.
365 Names of types only need to be unique within their container (model or package),
366 hence a package provides further name-spacing for type definitions.
367 When
368 deriving physical representations of a model, packages may be mapped to containers in the target
369 meta-model.
370 For example in mapping to XSD they may give rise to separate documents with type definitions and their
371 own targetNamespace. When generating
372 Java classes they may be used to define seprate packages for
373 the classes derived form the types.
374 </xsd:documentation>
375 </xsd:annotation>
376 <xsd:complexContent>
377 <xsd:extension base="ReferableElement">
378 <xsd:annotation>
379 <xsd:documentation>
380 Name of the package is constrained in that
381 there can only be one package with a given name
382 in the container in which the package is defined, i.e. the model or a parent package.
383 TBD we may wish to extend this rule to all children
384 defined in a container, including types.
385 </xsd:documentation>
386 </xsd:annotation>
387 <xsd:sequence>
388 <xsd:element name="primitiveType" type="PrimitiveType" minOccurs="0" maxOccurs="unbounded">
389 <xsd:annotation>
390 <xsd:documentation>
391 Collection of PrimitiveType-s defined in this package.
392 </xsd:documentation>
393 </xsd:annotation>
394 </xsd:element>
395 <xsd:element name="enumeration" type="Enumeration" minOccurs="0" maxOccurs="unbounded">
396 <xsd:annotation>
397 <xsd:documentation>
398 Collection of Enumeration-s defined in this package.
399 </xsd:documentation>
400 </xsd:annotation>
401 </xsd:element>
402 <xsd:element name="dataType" type="DataType" minOccurs="0" maxOccurs="unbounded">
403 <xsd:annotation>
404 <xsd:documentation>
405 Collection of DataType-s defined in this package.
406 </xsd:documentation>
407 </xsd:annotation>
408 </xsd:element>
409 <xsd:element name="objectType" type="ObjectType" minOccurs="0" maxOccurs="unbounded">
410 <xsd:annotation>
411 <xsd:documentation>
412 Collection of ObjectType-s defined in this package.
413 </xsd:documentation>
414 </xsd:annotation>
415 </xsd:element>
416 <xsd:element name="package" type="Package" minOccurs="0" maxOccurs="unbounded">
417 <xsd:annotation>
418 <xsd:documentation>
419 Collection of child Package-s defined in this package.
420 </xsd:documentation>
421 </xsd:annotation>
422 </xsd:element>
423 </xsd:sequence>
424 </xsd:extension>
425 </xsd:complexContent>
426
427 </xsd:complexType>
428
429
430 <xsd:complexType name="Type" abstract="true">
431 <xsd:annotation>
432 <xsd:documentation>
433 Base class of all type definition elements.
434 All Type-s extend ReferenceableElement, i.e. they are referencable.
435 Adds name, description, inheritance and indication of abstractness to ReferencableElement.
436 </xsd:documentation>
437 <xsd:documentation>
438 Name of the type. Must be unique in the collection of all types in a given container
439 (i.e. model or package)
440 </xsd:documentation>
441 </xsd:annotation>
442 <xsd:complexContent>
443 <xsd:extension base="ReferableElement">
444 <xsd:sequence>
445 <xsd:element name="extends" type="ElementRef" minOccurs="0">
446 <xsd:annotation>
447 <xsd:documentation>
448 Reference to a type (called the base-type) that is extended by the current type (called the subtype).
449 This implements the typical is-a inheritance relationship, similar to the extends relations in XSD and Java,
450 the
451 generaliation in UML, or the subclassOf relation in RDF. Note, VO-DML does not support multiple inheritance.
452 Instances of a subtype are automatic instances of a base type.
453 Polymorphism is assumed: When a role (see below) defines a base type
454 as its datatype, instances of any subtype
455 can be uased as value of the role.
456 Roles defined on a base type are inherited by the subtypes.
457 Relations inherited from a basetype can be 'subsetted', which is similar to overriding their definition.
458 See the definiton of this property on the Relation type.
459 </xsd:documentation>
460 </xsd:annotation>
461 </xsd:element>
462 <xsd:element name="constraint" type="Constraint" minOccurs="0" maxOccurs="unbounded">
463 <xsd:annotation>
464 <xsd:documentation>
465 Constraints defining valid instances of the type.
466 May be an AttributeConstraint or an expression in some language.
467 </xsd:documentation>
468 </xsd:annotation>
469 </xsd:element>
470
471 </xsd:sequence>
472 <xsd:attribute name="abstract" type="xsd:boolean" default="false" use="optional" />
473 </xsd:extension>
474 </xsd:complexContent>
475 </xsd:complexType>
476
477 <xsd:complexType name="ObjectType">
478 <xsd:annotation>
479 <xsd:documentation>
480 TBD use description form VO-DML specification document. to ...
481 </xsd:documentation>
482 </xsd:annotation>
483 <xsd:complexContent>
484 <xsd:extension base="Type">
485 <xsd:sequence>
486 <xsd:element name="attribute" type="Attribute" minOccurs="0" maxOccurs="unbounded">
487 <xsd:annotation>
488 <xsd:documentation>
489 TODO
490 </xsd:documentation>
491 </xsd:annotation>
492 </xsd:element>
493 <xsd:element name="collection" type="Composition" minOccurs="0" maxOccurs="unbounded">
494 <xsd:annotation>
495 <xsd:documentation>
496 TODO
497 </xsd:documentation>
498 </xsd:annotation>
499 </xsd:element>
500 <xsd:element name="reference" type="Reference" minOccurs="0" maxOccurs="unbounded">
501 <xsd:annotation>
502 <xsd:documentation>
503 TODO
504 </xsd:documentation>
505 </xsd:annotation>
506 </xsd:element>
507 </xsd:sequence>
508 </xsd:extension>
509 </xsd:complexContent>
510 </xsd:complexType>
511
512
513 <xsd:complexType name="ValueType" abstract="true">
514 <xsd:annotation>
515 <xsd:documentation>
516 Base class of all valaue types, i.e. those types identified by their value, rather than a separate explicit identifier.
517 These are the types that can be assigned to Attribute-s.
518 </xsd:documentation>
519 </xsd:annotation>
520 <xsd:complexContent>
521 <xsd:extension base="Type">
522 </xsd:extension>
523 </xsd:complexContent>
524 </xsd:complexType>
525
526
527 <xsd:complexType name="PrimitiveType">
528 <xsd:annotation>
529 <xsd:documentation>
530 Atomic/simple type. Defined by a single value. Generally a built in type from the IVOA profile model,
531 or a subclass of one of those types.
532 </xsd:documentation>
533 </xsd:annotation>
534 <xsd:complexContent>
535 <xsd:extension base="ValueType">
536 </xsd:extension>
537 </xsd:complexContent>
538 </xsd:complexType>
539
540 <xsd:complexType name="DataType">
541 <xsd:complexContent>
542 <xsd:extension base="ValueType">
543 <xsd:sequence>
544 <xsd:element name="attribute" type="Attribute" minOccurs="0" maxOccurs="unbounded">
545 <xsd:annotation>
546 <xsd:documentation>
547 TODO
548 </xsd:documentation>
549 </xsd:annotation>
550 </xsd:element>
551 <xsd:element name="reference" type="Reference" minOccurs="0" maxOccurs="unbounded">
552 <xsd:annotation>
553 <xsd:documentation>
554 TODO
555 </xsd:documentation>
556 </xsd:annotation>
557 </xsd:element>
558 </xsd:sequence>
559 </xsd:extension>
560 </xsd:complexContent>
561 </xsd:complexType>
562
563 <xsd:complexType name="Enumeration">
564 <xsd:annotation>
565 <xsd:documentation>
566 A primitive type with a limited, discrete set of values.
567 May explicitly extend a PrimitiveType. Its values must be compatible with that type then.
568 TBD Should define what it
569 might mean for an enumeraiton to extend another enumeration.
570 Should it restrict the possible values further? Or should it add to the values? Or ...?
571 </xsd:documentation>
572 </xsd:annotation>
573 <xsd:complexContent>
574 <xsd:extension base="PrimitiveType">
575 <xsd:sequence>
576 <xsd:element name="literal" type="EnumLiteral" maxOccurs="unbounded">
577 <xsd:annotation>
578 <xsd:documentation>
579 TODO
580 </xsd:documentation>
581 </xsd:annotation>
582 </xsd:element>
583 </xsd:sequence>
584 </xsd:extension>
585 </xsd:complexContent>
586 </xsd:complexType>
587
588 <xsd:complexType name="EnumLiteral">
589 <xsd:complexContent>
590 <xsd:extension base="ReferableElement">
591 <xsd:sequence>
592 </xsd:sequence>
593 </xsd:extension>
594 </xsd:complexContent>
595 </xsd:complexType>
596
597 <xsd:complexType name="Role" abstract="true">
598 <xsd:annotation>
599 <xsd:documentation>
600 A Role represents the "role a Type plays in the definition of another Type".
601 Generally, instances of structured types contain instances of other types, organised according to some
602 predesigned pattern consisting basically of
603 name-value pairs.
604 The names refer to the particular role to which the values are assigned.
605 These values must have the type corresponding to the role, implemented below using the datatype element.
606 The values may be multiple-valued.
607 Three different types
608 of roles are supported in VO-DML: Attribute, COllection and Reference.
609 Their characteristics are defined below.
610 </xsd:documentation>
611 <xsd:documentation>
612 Role extends ReferencableElement.
613 The 'name' element that is inherited from that type must be unique in the collection of roles
614 defined on the parent type.
615 This uniqueness must extend over the roles available on the type by
616 inheritance.
617 </xsd:documentation>
618 </xsd:annotation>
619
620 <xsd:complexContent>
621 <xsd:extension base="ReferableElement">
622 <xsd:sequence>
623 <xsd:element name="datatype" type="ElementRef">
624 <xsd:annotation>
625 <xsd:documentation>
626 Reference to the type that plays the role represented by this Role.
627 </xsd:documentation>
628 </xsd:annotation>
629 </xsd:element>
630 <xsd:element name="multiplicity" type="Multiplicity">
631 <xsd:annotation>
632 <xsd:documentation>
633 The multiplicity of the role (also called cardinality) indicates whether it must have a
634 value or may be without value, or possibly how many values are allowed.
635 </xsd:documentation>
636 </xsd:annotation>
637 </xsd:element>
638 <xsd:element name="subsets" type="ElementRef" minOccurs="0">
639 <xsd:annotation>
640 <xsd:documentation>
641 Represents the UML subsetted property. Indicates that a particular relation refines the definition
642 of another relation. ONly a relation inherited form a base class can
643 be subsetted. Typical usage is
644 that the base class has a
645 relation to a class A, and the subclass refines this to indicating that
646 the relation should be to a subclass of A.
647
648 The value should identify the subsetted property.
649 TBD IF we are going to use utype-s to refer to elements also inside this
650 document, we should use an
651 appropriate keyref
652 </xsd:documentation>
653 <xsd:documentation>
654 TBD this is a somewhat abstract, but very useful modeling concept.
655 It implements a very common modeling design pattern.
656 It exists in UML2.
657 </xsd:documentation>
658 </xsd:annotation>
659 </xsd:element>
660 </xsd:sequence>
661 </xsd:extension>
662 </xsd:complexContent>
663 </xsd:complexType>
664
665 <xsd:complexType name="Attribute">
666 <xsd:annotation>
667 <xsd:documentation>
668 An Attribute is a Role where the target datatype is a ValueType.
669 It represent "simple" properties of its container type, which can be an ObjectType or a DataType.
670 </xsd:documentation>
671 <xsd:documentation>
672 Must refer to a ValueType.
673 </xsd:documentation>
674 </xsd:annotation>
675 <xsd:complexContent>
676 <xsd:extension base="Role">
677 <xsd:sequence>
678 <xsd:element name="semanticconcept" type="SemanticConcept" minOccurs="0">
679 <xsd:annotation>
680 <xsd:documentation>
681 It is possible to assign a SEmanticConcept to an attribute definition.
682 This means that the values of the attribute have to comply with the definition of the
683 SemanticConcept.
684 This can be done in two manners. Either the SemanticConcept
685 gives a link to a semantic vocabulary, in which case the value must be a
686 concept defined in that vocabulary.
687 Or it defines a topConcept, in which case the value must be a concept that is explicitly
688 declared to be (narrower than)
689 that concept, or a concept that is narrower than that concept.
690 FOr details on the interpretation see the VO-DML document.
691 </xsd:documentation>
692 </xsd:annotation>
693 </xsd:element>
694 </xsd:sequence>
695 </xsd:extension>
696 </xsd:complexContent>
697 </xsd:complexType>
698
699
700
701 <xsd:complexType name="SemanticConcept">
702 <xsd:annotation>
703 <xsd:documentation>
704 Type used to indicate on attributes that they take values representing a concept defined in
705 an identified semantic vocabulary (SKOS or RDFS), and/or restricted by being narrower/more specific than an
706 identified "top" concept.
707 </xsd:documentation>
708 </xsd:annotation>
709 <xsd:sequence>
710 <xsd:element name="topConcept" type="xsd:anyURI" minOccurs="0">
711 <xsd:annotation>
712 <xsd:documentation>
713 A URI identifiying a semntic concept that corresponds to the concept in the model.
714 Values of a corresponding attributes must be URI-s identifiying objects that are narrower
715 than the identified concept. This attribute may be null as
716 certain vocabularies may not have a
717 </xsd:documentation>
718 </xsd:annotation>
719 </xsd:element>
720 <xsd:element name="vocabularyURI" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded">
721 <xsd:annotation>
722 <xsd:documentation>
723 If no topConcept is defined, one or more explicit vocabularies can be provided from which the
724 value must be obtained.
725 </xsd:documentation>
726 </xsd:annotation>
727 </xsd:element>
728 </xsd:sequence>
729 </xsd:complexType>
730
731 <xsd:complexType name="Relation" abstract="true">
732 <xsd:annotation>
733 <xsd:documentation>
734 A relation is a Role where the target datatype is an ObjectType.
735 </xsd:documentation>
736 </xsd:annotation>
737 <xsd:complexContent>
738 <xsd:extension base="Role">
739 <xsd:sequence>
740 </xsd:sequence>
741 </xsd:extension>
742 </xsd:complexContent>
743 </xsd:complexType>
744
745 <xsd:complexType name="Reference">
746 <xsd:annotation>
747 <xsd:documentation>
748 A Reference is a Relation that indicates a kind of "usage" relationship
749 between the target ObjectType and the owner of the reference, the "referrer".
750 The referrer can be an ObjectType (typically) but also a DataType.
751 The relation is
752 looser than the composition/collection relationship, acting like a
753 semantically meaningful pointer rather than indicating a component of the referrer.
754 Consequently, in general many referrers can point at the same target instance,
755 and ObjectType-s can
756 be the target in different reference definitions.
757 The lifecycle of the target is not bound to that of the referrer.
758 Often the target instance is used to provide a context for the definition of
759 the referrer. For example a coordinate frame may be
760 referenced to provide context to coordinate values.
761 TBD more needed ...?
762 </xsd:documentation>
763 </xsd:annotation>
764 <xsd:complexContent>
765 <xsd:extension base="Relation">
766 <xsd:annotation>
767 <xsd:documentation>
768 TBD Should have multiplicity 0..1 or 1?
769 </xsd:documentation>
770 </xsd:annotation>
771 </xsd:extension>
772 </xsd:complexContent>
773 </xsd:complexType>
774
775 <xsd:complexType name="Composition">
776 <xsd:annotation>
777 <xsd:documentation>
778 This type implements a composition relation between the parent and child ObjectTypes.
779 Its instances are ONLY used to set the "collection" field on an ObjectType.
780 It is a rule that an object type can only be the target of a single collection definition.
781 A subclass can be assigned a target to a collection if a
782 baseclass is already assigned such a target, but only if the collection is explicitly 'subsetted'.
783 A collection is assumed to be a set, i.e.
784 a given object (as identified by its identifier!) cannot occur
785 multiple times in the collection.
786 The collection
787 may be ordered, whichi implies that the order in whichi objects have been added
788 to
789 the collection is to be preserved. As clients can always do an explicit sort on any of the child objects' attributes,
790 it seems not necessary to add functionality for
791 declaring a collection is
792 sorted on one or more attributes.
793 Through the uniqueInCollection constraint that can be assigned to attributes, a collection can impose the
794 constraint that different objects in the collection
795 must have distinct values of the
796 attribute to which that constraint is assigned.
797 It would be better probably to add the capability to assign such constraints to this collection type.
798 This would
799 also give more flexibility in for example creating explicit (named) keys, or defining
800 multi-attribute uniqueness constraints.
801 </xsd:documentation>
802 </xsd:annotation>
803 <xsd:complexContent>
804 <xsd:extension base="Relation">
805 <xsd:sequence>
806 <xsd:element name="isOrdered" type="xsd:boolean" default="false" minOccurs="0">
807 <xsd:annotation>
808 <xsd:documentation>
809 If true, this collection preserves the ordering of object insertions.
810 </xsd:documentation>
811 </xsd:annotation>
812 </xsd:element>
813 </xsd:sequence>
814 </xsd:extension>
815 </xsd:complexContent>
816 </xsd:complexType>
817
818
819 <xsd:complexType name="Multiplicity">
820 <xsd:annotation>
821 <xsd:documentation>
822 Also called "Cardinality". Indicates how many instances of a datatype can/must be associated to a given role.
823 Unless
824 Follows model in XSD, i.e. with explicit lower bound and upper bound on number of instances.
825 maxOccurs must be gte minOccurs, unless it is negative, in which case it corresponds to unbounded.
826 </xsd:documentation>
827 </xsd:annotation>
828 <xsd:sequence>
829 <xsd:choice>
830 <xsd:element name="minOccurs" type="xsd:nonNegativeInteger" default="1">
831 <xsd:annotation>
832 <xsd:documentation>
833 Lower bound on number of instances/values.
834 </xsd:documentation>
835 </xsd:annotation>
836 </xsd:element>
837 </xsd:choice>
838 <xsd:element name="maxOccurs" type="xsd:int" default="1">
839 <xsd:annotation>
840 <xsd:documentation>
841 When negative, unbounded.
842 </xsd:documentation>
843 </xsd:annotation>
844 </xsd:element>
845 </xsd:sequence>
846 </xsd:complexType>
847
848
849 <xsd:complexType name="Constraint">
850 <xsd:annotation>
851 <xsd:documentation>
852 Constraint represents rules that instances of Type-s must obey to be valid.
853 A Constraint is a referable element. Its description element describes the constraint in English.
854 In future versions of the language extra elements may be added that give a more formal
855 definition of the constraint. In particular we may add expressions in a language
856 such as OCL or subset thereof tuned to VO-DML.
857 In terms of OCL, VO-DML COnstraint-s are invariants of a Type.
858 </xsd:documentation>
859 </xsd:annotation>
860 <xsd:complexContent>
861 <xsd:extension base="ReferableElement"></xsd:extension>
862 </xsd:complexContent>
863 </xsd:complexType>
864
865
866 <xsd:complexType name="RoleConstraint">
867 <xsd:annotation>
868 <xsd:documentation>
869 Constraint represents rules that instances of Type-s must obey to be valid.
870 A Constraint is a referable element. Its description element describes the constraint in English.
871 In future versions of the language extra elements may be added that give a more formal
872 definition of the constraint. In particular we may add expressions in a language
873 such as OCL or subset thereof tuned to VO-DML.
874 In terms of OCL, VO-DML COnstraint-s are invariants of a Type.
875 </xsd:documentation>
876 </xsd:annotation>
877 <xsd:complexContent>
878 <xsd:extension base="Constraint">
879 <xsd:sequence>
880 <xsd:element name="constrainedRole" type="ElementRef">
881 <xsd:annotation>
882 <xsd:documentation>
883 VODMLREF identifying the constrained Role.
884 This role MUST be available to the type containing this constraint.
885 </xsd:documentation>
886 </xsd:annotation>
887 </xsd:element>
888 <xsd:element name="subsets" type="ElementRef" minOccurs="0">
889 <xsd:annotation>
890 <xsd:documentation>
891 Pointer to datatype that the constrained Role must take.
892 This datatype MUST be a sub-type of the declared datatype of the constrained Role.
893 </xsd:documentation>
894 </xsd:annotation>
895 </xsd:element>
896 <xsd:element name="semanticconcept" type="SemanticConcept" minOccurs="0">
897 <xsd:annotation>
898 <xsd:documentation>
899 Maybe the super type has not defined a semantic concept for the Role, but
900 the subtype needs that. This attribute allows this assignment. But alse when
901 the Role on the super-type already has a semanticconcept with a topConcept
902 defined on it, the subtype may restrict the values to a narrower concept than
903 that assigned to it on the super-type.
904 </xsd:documentation>
905 </xsd:annotation>
906 </xsd:element>
907 </xsd:sequence>
908 </xsd:extension>
909 </xsd:complexContent>
910
911 </xsd:complexType>
912 <!--
913 The following, commented-out type definition is a proposal for an alternative way to define subsetting of roles.
914 It allows one to refine certain properties of an inherited role, without requiring a re-definition of the role itself.
915 The latter would lead to extra constraints on this role (e.g. name must not chnage) and a new vodml-id for the inherited role,
916 complicating interpretations, especially of "naive" clients as defined in the mapping document.
917 -->
918 <!--
919 <xsd:complexType name="SubsettingConstraint">
920 <xsd:annotation>
921 <xsd:documentation>
922 Implementation of the UML "subsets" concept as a special type of constraint.
923 </xsd:documentation>
924 </xsd:annotation>
925 <xsd:complexContent>
926 <xsd:extension base="Constraint">
927 <xsd:annotation>
928 <xsd:documentation>
929 The inherited description element of a SubsettingConstraint MAY be used to define custom cnstraints on the role.
930 IF not empty, "self" in the expression now refers to the Role on the instance, NOT the instance itself!
931 </xsd:documentation>
932 </xsd:annotation>
933 <xsd:sequence>
934 <xsd:element name="overrides" type="VODMLREF" minOccurs="1">
935 <xsd:annotation>
936 <xsd:documentation>
937 Identifies the role that is overridden. MUST identify a role inherited from a super type.
938 </xsd:documentation>
939 </xsd:annotation>
940 </xsd:element>
941 <xsd:element name="datatype" type="VODMLREF" minOccurs="0">
942 <xsd:annotation>
943 <xsd:documentation>
944 IF the subsetting constrains the role to a sub-type of the dattaype of the subseted ROle,
945 This element identifies this subtype. May be null if another feature is overriden.
946 </xsd:documentation>
947 </xsd:annotation>
948 </xsd:element>
949 <xsd:element name="multiplicity" type="Multiplicity" minOccurs="0">
950 <xsd:annotation>
951 <xsd:documentation>
952 IF the subsetting constrains the role to a sub-type of the dattaype of the subseted ROle,
953 This element identifies this subtype. May be null if another feature is overriden.
954 </xsd:documentation>
955 </xsd:annotation>
956 </xsd:element>
957 </xsd:sequence>
958 </xsd:extension>
959 </xsd:complexContent>
960 </xsd:complexType>
961 -->
962 <!-- Begin of element declaration(s) -->
963 <xsd:element name="model" type="Model">
964 <xsd:annotation>
965 <xsd:documentation>
966 Every VO-DML/XML document must start with a 'model' element, no other root elements are supported by this spec.
967 </xsd:documentation>
968 </xsd:annotation>
969 </xsd:element>
970
971
972 </xsd:schema>

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26