Changes between Version 2 and Version 3 of CmdiClavasIntegration

Timestamp:

12/05/12 14:52:23 (11 years ago)

Author:

twagoo

Comment:

Added example for element in profile specification

CmdiClavasIntegration

@@ -41 +41 @@
 {{{
 #!xml
-    <language clavas:id="http://cdb.iso.org/lg/CDB-00138580-001">Dutch</language>
+<language clavas:id="http://cdb.iso.org/lg/CDB-00138580-001">Dutch</language>
 }}}
 
@@ -49 +49 @@
 
 Vocabularies can be designated as either closed or open, and Arbil will present them accordingly but will always allow arbitrary input (as it does now). We have to accept that values cannot always be validated against closed vocabularies coming form an external service (in contrast to closed controlled vocabularies that come from the schema as we already have). Applications like Arbil and harvesters could have validation steps in addition to schema validation that check the validity of the values in elements that have a vocabulary reference. Possibly Schematron could be used to implement this.
+
+Taking these things into account, an element specification in a CMDI component or profile could look something like:
+
+{{{
+#!xml
+<CMD_Element 
+    name="Institution"
+    CardinalityMax="1" 
+    CardinalityMin="1" 
+    clavas:vocabulary="http://openskos.org/api/institutions"
+    clavas:type="open"
+    clavas:label="prefLabel"
+/>
+}}}
+
+The "clavas"-attributes could go straight into the generated profile XSD, pretty much like the "datcat"-attributes and read like that from the schema by client applications.
 
 === CLAVAS vocabulary sources ===