You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Apache Wiki <wi...@apache.org> on 2006/06/01 16:41:41 UTC

[Ws Wiki] Update of "Tuscany/TuscanyJava/Design/SDO/ChangeSummary" by KelvinGoodson

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by KelvinGoodson:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Design/SDO/ChangeSummary

------------------------------------------------------------------------------
  === The "mixed" approach ===
  Assuming that consistency of approach is a good place to start from, it would be sensible to follow the pattern of the inclusion of the mixed feature as a property of a class which occurs when mixed = true.  Finding this feature is based on annotation of the feature with a FEATURE_KIND, i.e. for the mixed feature this is ExtendedMetaData.ELEMENT_WILDCARD_FEATURE.
  
- ==== Things that would need to be done ====
+ ==== Issues/Things I can see that would need to be done ====
+  * meta model
+   * do I need to tweak this to reflect the presence of ChangeSummary?
+   * is there a definitive update?
+   * can the behaviour change be implemented without a change to the meta model?
+   * what is the definitive source of the meta model? SDO.mdl file? ecore? xsd?
+   * assumption: the meta model is the starting point for this development
+   * Is the Java rendering of the model created as part of the build?
+   * do I have the freedom to change the xsds and xml files in the sdo-api project, or are these fixed by the spec?
+   * '''sdoModel.xsd''' (meta meta model?) 
+    * either
+     * add attribute "changeSummary" (is that a good name? Ought to be an adjective) as a boolean to "Type"
+     * or perhaps it gets added via the anyAttribute and we update the sdoXML.xsd?
+   * '''sdoModel.xml''' facilitates a run time representation of the sdo model as object instances (but is that what it's for?)
+   * '''sdoJava.xsd'''
+    * perhaps the changeSummary attribute (or whatever its called) gets added as a global attribute in here,  and may be aded to the model by virtue of the xsd:anyAttribute on sdoModel.xsd (my feeling is that this should be a proper attribute on the model)
+   * '''datagraph.xsd'''
+    * the place where ChangeSummaryType type is defined
+    * referred to in a comment in sdoModel.xsd (maintenance?)
+    * 
   * generator
-   * new annotation on xsds
+   * handle new annotation on xsds
-   * recognise annotation and add new feature/getter
+   * add new feature and getter
   * run time
    * permit dynamic type creation with change summary attribute
+     * update class to indicate change summary tracking possible
+     * create new attribute with 
    * change getter behaviour on DataObject to look for CS on DO
+    * ? have BasicExtendedMetaData method similar to getContentKind which looks for annotation on EClass that changeSummary attribute present is true/false
+    * cycle over attributes, checking for getFeatureKind(eAttribute) == ExtendedMetaData.CHANGESUMMARY_FEATURE    
    * enumerate and guard new state invariants on runtime model
+    *
+    *
  
  
  == arbitrary snippets for inclusion ==

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org