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

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

Parent Directory Parent Directory | Revision Log Revision Log


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

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