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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3273 - (hide annotations)
Wed Mar 30 12:32:17 2016 UTC (5 years, 5 months ago) by gerard.lemson
File size: 43343 byte(s)
UPdates after Mark's comments on vo-dml doc.
1 omarlaurino@gmail.com 2738 <?xml version="1.0" encoding="UTF-8"?>
2     <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
3 gerard.lemson 3044 xmlns="http://www.ivoa.net/xml/VODML/v1.0"
4     targetNamespace="http://www.ivoa.net/xml/VODML/v1.0"
5 omarlaurino@gmail.com 2738 attributeFormDefault="unqualified" elementFormDefault="unqualified">
6    
7     <xsd:annotation>
8     <xsd:documentation>
9 gerard.lemson 2831
10 omarlaurino@gmail.com 2738 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 gerard.lemson 2831 TBD continue based on VO-DML specification document.
14     </xsd:documentation>
15 omarlaurino@gmail.com 2738 <xsd:documentation>
16     Look at SVN versions 2129 and earlier for more extensive model.
17     </xsd:documentation>
18     </xsd:annotation>
19    
20 gerard.lemson 2831 <!-- +++++++++++++++++++ Begin of 'Identifier section' +++++++++++++++++++ -->
21     <xsd:simpleType name="VODMLID" >
22 omarlaurino@gmail.com 2738 <xsd:annotation>
23     <xsd:documentation>
24 gerard.lemson 2831 Type representing the way referable elements are identified uniquely in VO-DML.
25 omarlaurino@gmail.com 2738 </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 gerard.lemson 2831 <xsd:simpleType name="ModelName">
39 omarlaurino@gmail.com 2738 <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 gerard.lemson 3273 <xsd:pattern value="[a-zA-Z][\w_-]*">
47 omarlaurino@gmail.com 2738 <xsd:annotation>
48     <xsd:documentation>
49 gerard.lemson 2831 A model name MUST NOT contain a semicolon.
50 omarlaurino@gmail.com 2738 </xsd:documentation>
51     </xsd:annotation>
52     </xsd:pattern>
53     </xsd:restriction>
54     </xsd:simpleType>
55    
56 gerard.lemson 2831 <xsd:simpleType name="VODMLREF">
57 omarlaurino@gmail.com 2738 <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 gerard.lemson 2831 Hence the VODMLREF must identify both model and element.
62 omarlaurino@gmail.com 2738 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 gerard.lemson 2831 TBD We could use an xsd:QName where VODMLREF is used, but that may have somewhat more sever syntax constraints than desired.
66 omarlaurino@gmail.com 2738 </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 gerard.lemson 3273 and a identifier that should follow the VODMLID restriction,
74 omarlaurino@gmail.com 2738 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 gerard.lemson 3273 <xsd:pattern value="[\w_-]+:[\w-/\._]+"/>
82 omarlaurino@gmail.com 2738 </xsd:restriction>
83     </xsd:simpleType>
84    
85 gerard.lemson 3038 <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 gerard.lemson 2831 <xsd:complexType name="ReferableElement" abstract="true">
105 omarlaurino@gmail.com 2738 <xsd:annotation>
106     <xsd:documentation>
107     This is the base type for all types whose elements can be explicitly referenced.
108 gerard.lemson 2831 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 omarlaurino@gmail.com 2738 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 gerard.lemson 2831 The VODMLREF type is used for such references, which will always be named 'vodml-ref'.
116 omarlaurino@gmail.com 2738 </xsd:documentation>
117     </xsd:annotation>
118     <xsd:sequence>
119 gerard.lemson 2831 <xsd:element name="vodml-id" type="VODMLID" minOccurs="1">
120 omarlaurino@gmail.com 2738 <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 gerard.lemson 3038 <xsd:element name="name" type="VODMLName" minOccurs="1" >
128 omarlaurino@gmail.com 2738 <xsd:annotation>
129     <xsd:documentation>
130 gerard.lemson 2831 The name of the model element.
131     MUST NOT be an empty string.
132 omarlaurino@gmail.com 2738 </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 gerard.lemson 2831 <xsd:element name="vodml-ref" type="VODMLREF">
171 omarlaurino@gmail.com 2738 <xsd:annotation>
172     <xsd:documentation>
173     The element identifying the referenced target element.
174 gerard.lemson 2831 See the documentation for the VODMLREF type.
175 omarlaurino@gmail.com 2738 </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 gerard.lemson 2831 <xsd:element name="name" type="ModelName" minOccurs="1" maxOccurs="1">
194 omarlaurino@gmail.com 2738 <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 gerard.lemson 2831 <xsd:element name="import" type="ModelImport" minOccurs="0" maxOccurs="unbounded">
246 omarlaurino@gmail.com 2738 <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 gerard.lemson 2842 <xsd:element name="primitiveType" type="PrimitiveType" minOccurs="0" maxOccurs="unbounded">
271 omarlaurino@gmail.com 2738 <xsd:annotation>
272     <xsd:documentation>
273 gerard.lemson 2842 Collection of PrimitiveType definitions directly under the model, i.e. not contained in a
274     Package.
275 omarlaurino@gmail.com 2738 </xsd:documentation>
276     </xsd:annotation>
277     </xsd:element>
278 gerard.lemson 2842 <xsd:element name="enumeration" type="Enumeration" minOccurs="0" maxOccurs="unbounded">
279 omarlaurino@gmail.com 2738 <xsd:annotation>
280     <xsd:documentation>
281 gerard.lemson 2842 Collection of Enumeration definitions directly under the model, i.e. not contained in a Package.
282 omarlaurino@gmail.com 2738 </xsd:documentation>
283     </xsd:annotation>
284     </xsd:element>
285 gerard.lemson 2842 <xsd:element name="dataType" type="DataType" minOccurs="0" maxOccurs="unbounded">
286 omarlaurino@gmail.com 2738 <xsd:annotation>
287     <xsd:documentation>
288 gerard.lemson 2842 Collection of DataType definitions directly under the model, i.e. not contained in a Package.
289 omarlaurino@gmail.com 2738 </xsd:documentation>
290     </xsd:annotation>
291     </xsd:element>
292 gerard.lemson 2842 <xsd:element name="objectType" type="ObjectType" minOccurs="0" maxOccurs="unbounded">
293 omarlaurino@gmail.com 2738 <xsd:annotation>
294     <xsd:documentation>
295 gerard.lemson 2842 Collection of ObjectType definitions directly under the model, i.e. not contained in a Package.
296 omarlaurino@gmail.com 2738 </xsd:documentation>
297     </xsd:annotation>
298     </xsd:element>
299 gerard.lemson 2833 <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 omarlaurino@gmail.com 2738 </xsd:sequence>
308     </xsd:complexType>
309    
310    
311 gerard.lemson 2831 <xsd:complexType name="ModelImport">
312 omarlaurino@gmail.com 2738 <xsd:annotation>
313     <xsd:documentation>
314 gerard.lemson 2831 A "proxy" for an external model that is being used by the current model.
315 omarlaurino@gmail.com 2738 Defines the url where the VO-DML representation of that model can be retrieved, and
316 gerard.lemson 2831 replicates its name that MUST be used when making references to
317     elements in that model using a VODMLREF element.
318 omarlaurino@gmail.com 2738 </xsd:documentation>
319     </xsd:annotation>
320     <xsd:sequence>
321 gerard.lemson 2831 <xsd:element name="name" type="ModelName" minOccurs="1">
322 omarlaurino@gmail.com 2738 <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 gerard.lemson 2842 <xsd:element name="version" type="xsd:string" minOccurs="0">
331 omarlaurino@gmail.com 2738 <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 gerard.lemson 2831 <xsd:extension base="ReferableElement">
378 omarlaurino@gmail.com 2738 <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 gerard.lemson 2842 <xsd:element name="primitiveType" type="PrimitiveType" minOccurs="0" maxOccurs="unbounded">
389 omarlaurino@gmail.com 2738 <xsd:annotation>
390     <xsd:documentation>
391 gerard.lemson 2842 Collection of PrimitiveType-s defined in this package.
392 omarlaurino@gmail.com 2738 </xsd:documentation>
393     </xsd:annotation>
394     </xsd:element>
395 gerard.lemson 2842 <xsd:element name="enumeration" type="Enumeration" minOccurs="0" maxOccurs="unbounded">
396 omarlaurino@gmail.com 2738 <xsd:annotation>
397     <xsd:documentation>
398 gerard.lemson 2842 Collection of Enumeration-s defined in this package.
399 omarlaurino@gmail.com 2738 </xsd:documentation>
400     </xsd:annotation>
401     </xsd:element>
402 gerard.lemson 2842 <xsd:element name="dataType" type="DataType" minOccurs="0" maxOccurs="unbounded">
403 omarlaurino@gmail.com 2738 <xsd:annotation>
404     <xsd:documentation>
405 gerard.lemson 2842 Collection of DataType-s defined in this package.
406 omarlaurino@gmail.com 2738 </xsd:documentation>
407     </xsd:annotation>
408     </xsd:element>
409 gerard.lemson 2842 <xsd:element name="objectType" type="ObjectType" minOccurs="0" maxOccurs="unbounded">
410 omarlaurino@gmail.com 2738 <xsd:annotation>
411     <xsd:documentation>
412 gerard.lemson 2842 Collection of ObjectType-s defined in this package.
413 omarlaurino@gmail.com 2738 </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 gerard.lemson 2831 <xsd:extension base="ReferableElement">
444 omarlaurino@gmail.com 2738 <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 gerard.lemson 2831 TBD use description form VO-DML specification document. to ...
481 omarlaurino@gmail.com 2738 </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 gerard.lemson 2831 <xsd:extension base="ReferableElement">
591 omarlaurino@gmail.com 2738 <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 gerard.lemson 2831 <xsd:extension base="ReferableElement">
622 omarlaurino@gmail.com 2738 <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 gerard.lemson 3038 <xsd:element name="semanticconcept" type="SemanticConcept" minOccurs="0">
679 omarlaurino@gmail.com 2738 <xsd:annotation>
680     <xsd:documentation>
681 gerard.lemson 3038 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 omarlaurino@gmail.com 2738 concept defined in that vocabulary.
687 gerard.lemson 3038 Or it defines a topConcept, in which case the value must be a concept that is explicitly
688 omarlaurino@gmail.com 2738 declared to be (narrower than)
689     that concept, or a concept that is narrower than that concept.
690 gerard.lemson 3038 FOr details on the interpretation see the VO-DML document.
691 omarlaurino@gmail.com 2738 </xsd:documentation>
692     </xsd:annotation>
693     </xsd:element>
694     </xsd:sequence>
695     </xsd:extension>
696     </xsd:complexContent>
697     </xsd:complexType>
698    
699    
700    
701 gerard.lemson 3038 <xsd:complexType name="SemanticConcept">
702 omarlaurino@gmail.com 2738 <xsd:annotation>
703     <xsd:documentation>
704     Type used to indicate on attributes that they take values representing a concept defined in
705 gerard.lemson 3038 an identified semantic vocabulary (SKOS or RDFS), and/or restricted by being narrower/more specific than an
706     identified "top" concept.
707 omarlaurino@gmail.com 2738 </xsd:documentation>
708     </xsd:annotation>
709     <xsd:sequence>
710 gerard.lemson 3038 <xsd:element name="topConcept" type="xsd:anyURI" minOccurs="0">
711 omarlaurino@gmail.com 2738 <xsd:annotation>
712     <xsd:documentation>
713 gerard.lemson 3038 A URI identifiying a semntic concept that corresponds to the concept in the model.
714 omarlaurino@gmail.com 2738 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 gerard.lemson 3038 If no topConcept is defined, one or more explicit vocabularies can be provided from which the
724 omarlaurino@gmail.com 2738 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 gerard.lemson 3038 <xsd:choice>
830 omarlaurino@gmail.com 2738 <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 gerard.lemson 3038 </xsd:choice>
838 omarlaurino@gmail.com 2738 <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 gerard.lemson 2831 Constraint represents rules that instances of Type-s must obey to be valid.
853 gerard.lemson 3038 A Constraint is a referable element. Its description element describes the constraint in English.
854 gerard.lemson 2831 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 omarlaurino@gmail.com 2738 </xsd:documentation>
859     </xsd:annotation>
860 gerard.lemson 3045 <xsd:sequence>
861     <xsd:element name="description" type="xsd:string" minOccurs="0">
862     <xsd:annotation>
863     <xsd:documentation>
864     A natural language description of the constraint.
865     </xsd:documentation>
866     </xsd:annotation>
867     </xsd:element>
868     </xsd:sequence>
869 omarlaurino@gmail.com 2738 </xsd:complexType>
870 gerard.lemson 3038
871    
872 gerard.lemson 3044 <xsd:complexType name="SubsettedRole">
873 gerard.lemson 3038 <xsd:annotation>
874     <xsd:documentation>
875     Constraint represents rules that instances of Type-s must obey to be valid.
876     A Constraint is a referable element. Its description element describes the constraint in English.
877     In future versions of the language extra elements may be added that give a more formal
878     definition of the constraint. In particular we may add expressions in a language
879     such as OCL or subset thereof tuned to VO-DML.
880     In terms of OCL, VO-DML COnstraint-s are invariants of a Type.
881     </xsd:documentation>
882     </xsd:annotation>
883     <xsd:complexContent>
884     <xsd:extension base="Constraint">
885     <xsd:sequence>
886 gerard.lemson 3046 <xsd:element name="role" type="ElementRef">
887 gerard.lemson 3038 <xsd:annotation>
888     <xsd:documentation>
889     VODMLREF identifying the constrained Role.
890     This role MUST be available to the type containing this constraint.
891     </xsd:documentation>
892     </xsd:annotation>
893     </xsd:element>
894 gerard.lemson 3044 <xsd:element name="datatype" type="ElementRef" minOccurs="0">
895 gerard.lemson 3038 <xsd:annotation>
896     <xsd:documentation>
897     Pointer to datatype that the constrained Role must take.
898     This datatype MUST be a sub-type of the declared datatype of the constrained Role.
899     </xsd:documentation>
900     </xsd:annotation>
901     </xsd:element>
902     <xsd:element name="semanticconcept" type="SemanticConcept" minOccurs="0">
903     <xsd:annotation>
904     <xsd:documentation>
905     Maybe the super type has not defined a semantic concept for the Role, but
906     the subtype needs that. This attribute allows this assignment. But alse when
907     the Role on the super-type already has a semanticconcept with a topConcept
908     defined on it, the subtype may restrict the values to a narrower concept than
909     that assigned to it on the super-type.
910     </xsd:documentation>
911     </xsd:annotation>
912     </xsd:element>
913     </xsd:sequence>
914     </xsd:extension>
915     </xsd:complexContent>
916    
917     </xsd:complexType>
918     <!--
919     The following, commented-out type definition is a proposal for an alternative way to define subsetting of roles.
920     It allows one to refine certain properties of an inherited role, without requiring a re-definition of the role itself.
921     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,
922     complicating interpretations, especially of "naive" clients as defined in the mapping document.
923     -->
924     <!--
925     <xsd:complexType name="SubsettingConstraint">
926     <xsd:annotation>
927     <xsd:documentation>
928     Implementation of the UML "subsets" concept as a special type of constraint.
929     </xsd:documentation>
930     </xsd:annotation>
931     <xsd:complexContent>
932     <xsd:extension base="Constraint">
933     <xsd:annotation>
934     <xsd:documentation>
935     The inherited description element of a SubsettingConstraint MAY be used to define custom cnstraints on the role.
936     IF not empty, "self" in the expression now refers to the Role on the instance, NOT the instance itself!
937     </xsd:documentation>
938     </xsd:annotation>
939     <xsd:sequence>
940     <xsd:element name="overrides" type="VODMLREF" minOccurs="1">
941     <xsd:annotation>
942     <xsd:documentation>
943     Identifies the role that is overridden. MUST identify a role inherited from a super type.
944     </xsd:documentation>
945     </xsd:annotation>
946     </xsd:element>
947     <xsd:element name="datatype" type="VODMLREF" minOccurs="0">
948     <xsd:annotation>
949     <xsd:documentation>
950     IF the subsetting constrains the role to a sub-type of the dattaype of the subseted ROle,
951     This element identifies this subtype. May be null if another feature is overriden.
952     </xsd:documentation>
953     </xsd:annotation>
954     </xsd:element>
955     <xsd:element name="multiplicity" type="Multiplicity" minOccurs="0">
956     <xsd:annotation>
957     <xsd:documentation>
958     IF the subsetting constrains the role to a sub-type of the dattaype of the subseted ROle,
959     This element identifies this subtype. May be null if another feature is overriden.
960     </xsd:documentation>
961     </xsd:annotation>
962     </xsd:element>
963     </xsd:sequence>
964     </xsd:extension>
965     </xsd:complexContent>
966     </xsd:complexType>
967     -->
968 gerard.lemson 2831 <!-- Begin of element declaration(s) -->
969 omarlaurino@gmail.com 2738 <xsd:element name="model" type="Model">
970     <xsd:annotation>
971     <xsd:documentation>
972     Every VO-DML/XML document must start with a 'model' element, no other root elements are supported by this spec.
973     </xsd:documentation>
974     </xsd:annotation>
975     </xsd:element>
976    
977    
978     </xsd:schema>

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