ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

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

ViewVC Help
Powered by ViewVC 1.1.26