Changes between Version 9 and Version 10 of CMDI 1.2/Cues/Derived values

Timestamp:

02/17/14 16:06:52 (10 years ago)

Author:

teckart

Comment:

+proposal 2

CMDI 1.2/Cues/Derived values

@@ -26 +26 @@
 * How will this information be generated and by whom? (Part of component registry/separate editor,separate registry?)
 
-== Proposed solution ==
+
+== First solution ==
+
 The idea is to specify a generic solution for value derivation in CMDI 1.2 without specific restrictions on allowed functions or constants. This is particularly important as there was no broader evaluation of needed functionality (and the above mentioned examples are probably just a start). Furthermore additional extensions in the infrastructure that are needed to support this functionality can be developed at a later time (as long as they are not directly related to the CMDI 1.2 specification process).
 
@@ -36 +38 @@
 
 ==== Cons ====
-* Needs additional components in the infrastructure, namely: a "function registry" where the semantics of all operations/constants is described and all allowed arguments are defined (semantics + allowed datatypes).
-* The proposed solution does not guarantee that referenced nodes do exist (usage of a component in various contexts or when refering to optional elements). This is especially important for derivation of values depending on component-external elements. In this case the editor should notify the user of this problem.
+* needs additional components in the infrastructure, namely: a "function registry" where the semantics of all operations/constants is described and all allowed arguments are defined (semantics + allowed datatypes).
+* the proposed solution does not guarantee that referenced nodes do exist (usage of a component in various contexts or when refering to optional elements). This is especially important for derivation of values depending on component-external elements. In this case the editor should notify the user of this problem.
 
 
@@ -88 +90 @@
 
 
-
+==== Open questions ====
+* Using new namespace?
+
+== Second solution ==
+A simpler solution would be to define a fixed set of functions (numeric operations + some frequently used functions like replacement of language codes with language names) and keywords (like $filesize, $current_time etc.)).
+
+The CMD general component schema is extended with one additional (optional) attribute (AutoValue) for the elements and attributes specification. This attribute contains the function that is used to generate the content of the element/attribute and is based on these predefined functions and keywords. Content of other elements that is needed to generate the value is addressed by using XPath expressions.
+
+
+==== Pros ====
+* simpler solution as proposal 1 (reduces implementation effort)
+* no need to build new infrastructure components
+
+==== Cons ====
+* may lack expressiveness (missing functions may become clear at some later point)
+* adding new functions needs changes in all editors (may occur regularly)
+* the proposed solution does not guarantee that referenced nodes do exist (usage of a component in various contexts or when refering to optional elements). This is especially important for derivation of values depending on component-external elements. In this case the editor should notify the user of this problem.
+
+==== Centre impact ====
+
+* Affected tools
+ * Infrastructure
+  * Component Registry
+ * Editors
+  * Arbil
+  * ProForma
+ * Viewers
+  * 
+* Impact on instances
+
+=== Implementation examples ===
+The specification of CMDI elements and attributes is extended by one optional attribute (AutoValue (xs:string)).
+{{{
+<!-- list of all attributes that can be bound to a cl_el -->
+    <xs:attributeGroup name="clarin_element_attributes">
+        <xs:attribute name="name" type="xs:Name" use="required">
+            <xs:annotation>
+                <xs:documentation>The name of the element.</xs:documentation>
+            </xs:annotation>
+        </xs:attribute>
+        ...
+        <xs:attribute name="AutoValue" type="xs:string">
+            <xs:annotation>
+                <xs:documentation>A function that is used to derive the content of this element based on external information.</xs:documentation>
+            </xs:annotation>
+        </xs:attribute>
+    </xs:attributeGroup>
+}}}
+and similar for Attribute specifications 
+
+==== Implementation on component model level ====
+Example:
+{{{
+<CMD_Element name="AgeOfFile" AutoValue="$CurrentDate-date({../CreationDate})"/>
+}}}
+
+
+
+==== Open questions ====
+* Using new namespace?
+* Allowed syntax?
 
 {{{#!comment
@@ -131 +193 @@
 [[TicketQuery(keywords=~derivedvalues,milestone=CMDI 1.2,format=table,col=summary|owner|component|priority|status)]]
 
+
 == Discussion ==