[Corelinux-clcvs] CVS: htdocs/develop develop.dvi,1.10,1.11 develop.pdf,1.10,1.11 develop.ps,1.10,1.11 develop.tex,1.10,1.11 develop.txt,1.7,1.8

[Frank V. C. <fr...@us...>]

Update of /cvsroot/corelinux/htdocs/develop
In directory usw-pr-cvs1:/tmp/cvs-serv21759

Modified Files:
	develop.dvi develop.pdf develop.ps develop.tex develop.txt 
Log Message:
Schema Update

Index: develop.dvi
===================================================================
RCS file: /cvsroot/corelinux/htdocs/develop/develop.dvi,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -r1.10 -r1.11
Binary files /tmp/cvsodazZa and /tmp/cvsYXEBDb differ

Index: develop.pdf
===================================================================
RCS file: /cvsroot/corelinux/htdocs/develop/develop.pdf,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -r1.10 -r1.11
Binary files /tmp/cvsYUyb7b and /tmp/cvsa8vQTh differ

Index: develop.ps
===================================================================
RCS file: /cvsroot/corelinux/htdocs/develop/develop.ps,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -r1.10 -r1.11
*** develop.ps	2000/10/07 17:16:56	1.10
--- develop.ps	2001/04/29 10:45:41	1.11
***************
*** 2,6 ****
  %%Creator: dvips(k) 5.86 Copyright 1999 Radical Eye Software
  %%Title: develop.dvi
! %%Pages: 11
  %%PageOrder: Ascend
  %%BoundingBox: 0 0 596 842
--- 2,6 ----
  %%Creator: dvips(k) 5.86 Copyright 1999 Radical Eye Software
  %%Title: develop.dvi
! %%Pages: 14
  %%PageOrder: Ascend
[...2287 lines suppressed...]
! (recognize)e(as)i(an)g(indicator)1449 5589 y Fg(13)p
! eop
! %%Page: 14 14
! 14 13 bop 0 -228 a Fd(REFERENCES)1738 b(REFERENCES)p
! 0 -191 2989 4 v 0 91 a Ff(that)47 b(the)g(application)d(whats)j
! (instances)e(of)i(this)g(data)f(member)g(to)i(be)f(handled)0
! 204 y(as)g(a)h(separate)d(table/file/etc.)f(according)h(to)i(it's)g
! (\(storage)e(service\))0 317 y(domain.)141 505 y Fg(Please)37
! b(note)h(that)f(these)g(w)m(ould)f(b)s(e)g(considered)g("suggestions")i
! (that)f(the)g(declaration)g(of)g(whic)m(h)e(do)s(es)0
! 618 y(not)c(imply)d(that)j(a)f(storage)i(service)e(w)m(ould)g(do)g(an)m
! (ything)g(with)f(the)h(information.)0 904 y Fi(References)0
! 1107 y Fg(FSF.)41 b Fa(GNU)32 b(A)n(uto)-5 b(c)g(onf)33
! b(Manual)p Fg(.)41 b(FSF,)31 b(2.13)h(edition,)d(1999.)0
! 1295 y(FSF.)41 b Fa(GNU)32 b(A)n(utomake)g(Manual)p Fg(.)42
! b(FSF,)30 b(1.4)i(edition,)d(2000a.)0 1482 y(FSF.)41
! b Fa(GNU)32 b(Libto)-5 b(ol)34 b(Manual)p Fg(.)41 b(FSF,)31
! b(1.3.4)h(edition,)d(2000b.)1449 5589 y(14)p eop
  %%Trailer
  end

Index: develop.tex
===================================================================
RCS file: /cvsroot/corelinux/htdocs/develop/develop.tex,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -r1.10 -r1.11
*** develop.tex	2000/10/07 17:16:57	1.10
--- develop.tex	2001/04/29 10:45:41	1.11
***************
*** 516,524 ****
  Whether managing graphic libraries, supporting plug-ins for extension, or dynamically calling shared library functions, applications often have a need to load information at run-time through the support of some library or operating system facility. The Library Load Framework supplies the extensible object types and behvioral semantics for such activities.
  
! \subsection{Persistence}
! \label{sec:Persist}
  
! There are many C++ applications that require the object instances to be saved and loaded for use across application or machine sessions.
  
  \bibliographystyle{plainnat}
   \bibliography{corelinux}
--- 516,680 ----
  Whether managing graphic libraries, supporting plug-ins for extension, or dynamically calling shared library functions, applications often have a need to load information at run-time through the support of some library or operating system facility. The Library Load Framework supplies the extensible object types and behvioral semantics for such activities.
  
! \subsection{Schemas And Persistence}
! \label{sec:SchmPersist}
  
! \subsubsection{Premise}
! \label{sec:SchmPersistPrem}
  
+ The persistence abstraction is built on the premise that the actual storage service code, that which implements concrete persist services beneath the abstraction, should be intelligent enough to take guidance from domain descriptions (concepts). Said concepts define the types to be stored, in addition to other information, and it is the job of the storage service to manage the data layout and service execution as defined by it's implementation.
+ 
+ It is, after all, the 21st century.
+ 
+ This benefits the application developer from having to worry about the details of a particular storage service, as well as having the flexibility to change persist implementations at will, or by user choice. 
+ \subsubsection{Overview}
+ \label{sec:SchmPersistOvr}
+ 
+ There are actually two (2) aspects to the CoreLinux++ Abstract Persist framework: Schemas and Services. This release focuses on the newly provided Schema constructs. * Please refer to the current implementation restrictions at the end of this document.
+ 
+ A Schema is an organization of concepts to model an idea. In this case, what is being modeled are the types that the application will want to have made persistent. When a schema has been modeled, it is then usable as a roadmap, in effect, to guide the storage implementation. For example, the types may represent tables in a relational database storage service, or a file type for a flat file service. It is ultimatley up to the service to decide how to "plan the trip".
+ 
+ There are two (2) workflows around Schemas and their concepts: Model and Run. Lets talk turkey first:
+ 
+ \subsubsection{Schema Modeling}
+ \label{sec:SchmPersistMod}
+ 
+ Schema modeling is supported through built-in services and functions of the library. All modeling changes are persisted to gdbm databases, and the domain modeler need only focus on making their schema correct. While there is a tremendous opportunity for adventerous open source developers to build tools around this (GUI, etc.), the library contains the fundemental capabilities to Create, Request, Update, and Delete Schemas or their artifacts (concepts).
+ 
+ The example test driver (clfw/src/testdrivers/exf2) shows some of the following capabilities. 
+ 
+ 1. Typically, start by resolving the SchemaSponsor and creating an
+ instance of it.
+ 
+ 2. From the Sponser, get the Catalog object instance.
+ 
+ 3. Create, Edit, Save, Close, Delete Schemas using the interface
+ of the Catalog instance.
+ 
+ 4. Create Concepts and add to Schema
+ 
+ 5. Remove Concepts from Schema and delete
+ 
+ \subsubsection{Schema Run Time}
+ \label{sec:SchmPersistRun}
+ 
+ Once a Schema has been modeled, it can be used by a storage service to support the input and output operations of application objects.
+ 
+ 1. Like Schema modeling, the activation of persistence in an application starts with the resolving and instance creation of a StoreSponser. This can be done be either using the the StoreSponser class name and resolving through the Ontology interfaces.
+ 
+ For example:
+ 
+       StoreSponsorPtr   aSponsor
+          (
+             StoreSponsor::castDown(getInstanceOf("MySQLSponsor"))
+          );
+ 
+ or by walking the StoreSponser MetaClass hierarchy and testing each of the children nodes until you find the one you want. In latter releases we will have support for descriptive attributes on MetaClasses to help reason with sponser types and capabilities.
+ 
+ Another way to load a Sponser would be to work in conjunction with plug-in support to dynamically load types that are not part of the library compilation. Sounds like a job for the CoreLinux++ Library Load 
+ capability!
+ 
+ Note: In the above code example it presumes that someone has provided a MySQL persistence implementation.
+ 
+ 2. From the Sponser, get the Catalog object instance.
+ 
+ 3. Create a Store (which would require identifying the Schema to be used
+ as the roadmap).
+ 
+ 4. Fetch a Store to write and read application object instances from and
+ to respectivley.
+ 
+ \subsubsection{Current Restrictions}
+ \label{sec:SchmPersistRest}
+ 
+ Name/Value Declarations
+ 
+ While ultimately Schemas and Concepts attributes won't be limited as to the
+ depth or types supported, the current implementation assumes most attributes
+ are of the form: Name:Value, where:
+ 
+ Name is the Key data member of the Attribute and should be of type 
+ FrameworkString
+ 
+ Value is the Value data member of the Attribute and should be of type 
+ FrameworkString
+ 
+ Primary Schema Declarations
+ 
+ For schemas, the following are the recognized attribute keys:
+ \begin{verbatim}
+ Attribute Key  	: "Name"
+ Expected Value 	: Unique name for this schema
+ Example		: "Franks Schema" 
+ Note		: This is a required attribute
+ 
+ Attribute Key  	: "Collection"
+ Expected Value 	: The collection type literal (currently "Array" or "SetCollection")
+ Note 		: SetCollection is safer for insuring unique name keys, although as new collection types are added it is really up to the modeling support.
+ Note		: This is a required attribute
+ 
+ Attribute Key  	: "Location"
+ Expected Value 	: Qualified path where schema should be stored
+ Note 		: This is an optional attribute, default is ~/.clfw++/schemas/"Name"
+ 
+ Attribute Key  	: "GUID"
+ Expected Value 	: Stringified UniversalIdentifier to be used
+ Note		: This is an optional attribute, default is the system will generate.
+ \end{verbatim}
+ 
+ with the following attribute expected to be supported in later releases:
+ 
+ \begin{verbatim}
+ Attribute Key  	: "SchemaClass"
+ Expected Value 	: The Schema class type literal to be used when instantiating a new schema, this will be stored with the Schema descriptor and will be used when reloading in new sessions.
+ Example		: "FranksWickedSchemaDerivation"
+ \end{verbatim}
+ 	 
+ Primary Concept Declarations
+ \begin{verbatim}
+ Attribute Key  	: "Name"
+ Expected Value 	: Unique name for this schema
+ Example		: "Concept A1" 
+ Note		: Even though concepts can be created for other reasons, this is a required attribute if adding to a Schema
+ 
+ Attribute Key  	: "Class"
+ Expected Value 	: Stringified UniversalIdentifier of the type that this Concept defines representation of to the storage service.
+ Note		: Even though concepts can be created for other reasons, this is a required attribute if adding to a Schema
+ \end{verbatim}
+ 
+ with the following attributes expected to be supported in later releases:
+ \begin{verbatim}
+ Attribute Key  : "Uses"
+ Expected Value : Collection type, where the collection contains attributes that describe data types of this object should reuse the storage managed by another concepts definition, therefore the nested attributes are:
+ 	Attribute Key  : "Data Member Name"
+ 	Expected Value : "Concept Name"
+ 
+ 		where:
+ 	
+ 			"Data Member Name" is the name of the data member that has been 
+ 			explicitly identified in the MetaClass definition of the entity 
+ 			being stored.
+ 	
+ 			"Concept Name" is the name of another concept in the Schema 
+ 			(which one would have to presume is the same type of the Data 
+ 			Member).
+ 
+ 	Attribute Key  : "Ignore"
+ 	Expected Value : Collection type, where the collection contains
+ 	single string values that identify (by name) the Data Members of 
+ 	the Class that the storage management should ignore. In 
+ 	otherword don't write or expect to read from persist.
+ 	
+ 	Attribute Key : "Fence"
+ 	Expected Value : Collection type, where the collection contains
+ 	single string values that identify (by name) the Data Members of
+ 	the Class that the storage manager should recognize as an indicator
+ 	that the application whats instances of this data member to be handled
+ 	as a separate table/file/etc. according to it's (storage service) 
+ 	domain.
+ \end{verbatim}
+ 
+ Please note that these would be considered "suggestions" that the declaration of which does not imply that a storage service would do anything with the information.
+ 
+ 
  \bibliographystyle{plainnat}
   \bibliography{corelinux}
***************
*** 536,537 ****
--- 692,702 ----
  % TeX-command-default: "PdfLaTeX"
  % End:
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 

Index: develop.txt
===================================================================
RCS file: /cvsroot/corelinux/htdocs/develop/develop.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -r1.7 -r1.8
*** develop.txt	2000/10/07 17:16:57	1.7
--- develop.txt	2001/04/29 10:45:41	1.8
***************
*** 9,54 ****
  
  
!                                                    Revision:  1.9
  
                                             Created on June 04, 2000
!                                            Revised on September 5, 2000
                                                        Abstract
  
!            This document describes how to build applications|with CoreLinux++ Standards.  This is
         the CoreLinux++ Development Guide.                   |
                                                              |
                                                              |
! Contents                                                    ||3    Standard Development Process         4
                                                              |
! 1   Introduction                                   2        ||4    Developing with CoreLinux++         4
                                                              |
! 
! 2   Setting Up for CoreLinux++ builds    2                  ||     4.1   Using autoconf   . . . . . . . . . .     4
!     2.1    Getting Things Rolling . . . . . .     2         ||     4.2   Macros . . . . . . . . . . . . . . .     5
!     2.2    Make Environment  . . . . . . . .     2          ||
!     2.3    Setting up for CoreLinux++ Ex-                   ||5    Class Library Internals                     8
!            ecution . . . . . . . . . . . . . . .     2      |      5.1   Foundation Classes  . . . . . . . .     9
!     2.4    Directory Structure . . . . . . . .     3        ||     5.2   Inter-Process Communication  . .     9
!            2.4.1    The Root Directory   . . .     3        ||           5.2.1    Semaphore and Semaphore-
!            2.4.2    The Root Include . . . . .     3        ||                    Group  . . . . . . . . . . .     9
!            2.4.3    The Root Source Root  . .     3         ||           5.2.2    Threads  . . . . . . . . . .     9
!            2.4.4    Class Library Source Root      4        |      5.3   Design Patterns  . . . . . . . . . .     9
!            2.4.5    CoreLinux  Class  Library               ||
!                     Source  . . . . . . . . . . .     4     ||6    Frameworks                                  10
!            2.4.6    Additional  Class  Library              ||     6.1   Framework Support   . . . . . . .    10
!                     Source  . . . . . . . . . . .     4     ||     6.2   Meta-class MetaType   . . . . . .    10
!            2.4.7    The  Test  Driver  and  Ex-             ||
!                     ample Code Root  . . . . .     4        |      6.3   MetaType Macros   . . . . . . . .    10
!            2.4.8    Example application source    4         ||     6.4   Ontology   . . . . . . . . . . . . .    10
!            2.4.9    CoreLinux++   Documen-                  ||     6.5   MetaType Ontology   . . . . . . .    10
!                     tation    for    Standards,             ||     6.6   Common franework abstractions      11
!                     Class  Reference,  Require-             ||           6.6.1    Library Load  . . . . . . .    11
!                     ments, Analysis, and Design   4         |      6.7   Persistence   . . . . . . . . . . . .    11
  Copyright  notice
  
  
  CoreLinux++ Copyright  cO  1999,  2000  CoreLinux  Consortium
! Revision  1.9 Last  Modified:   September  5,  2000
! This material may be distributed only subject to the terms and conditions set forth in the Open
  
  
--- 9,56 ----
  
  
!                                                    Revision:  1.10
  
                                             Created on June 04, 2000
!                                              Revised on October 7, 2000
                                                        Abstract
  
!            This document describes how to build applications|with|CoreLinux++ Standards.  This is
         the CoreLinux++ Development Guide.                   |
                                                              |
                                                              |
! Contents                                                    ||4    Developing with CoreLinux++         4
! 
!                                                             |      4.1   Using autoconf   . . . . . . . . . .     4
! 1   Introduction                                   2        ||     4.2   Macros . . . . . . . . . . . . . . .     5
                                                              |
! 2   Setting Up for CoreLinux++ builds    2                  ||5    Class Library Internals                     8
!     2.1    Getting Things Rolling . . . . . .     2         ||     5.1   Foundation Classes  . . . . . . . .     9
!     2.2    Make Environment  . . . . . . . .     2          ||     5.2   Inter-Process Communication  . .     9
!     2.3    Setting up for CoreLinux++ Ex-                   |            5.2.1    Semaphore and Semaphore-
!            ecution . . . . . . . . . . . . . . .     2      ||                    Group  . . . . . . . . . . .     9
!     2.4    Directory Structure . . . . . . . .     3        ||           5.2.2    Threads  . . . . . . . . . .     9
!            2.4.1    The Root Directory   . . .     3        ||     5.3   Design Patterns  . . . . . . . . . .     9
!            2.4.2    The Root Include . . . . .     3        ||
!            2.4.3    The Root Source Root  . .     3         | 6    Frameworks                                  10
!            2.4.4    Class Library Source Root      4        ||     6.1   Framework Support   . . . . . . .    10
!            2.4.5    CoreLinux  Class  Library               ||     6.2   Meta-class MetaType   . . . . . .    10
!                     Source  . . . . . . . . . . .     4     ||     6.3   MetaType Macros   . . . . . . . .    10
!            2.4.6    Additional  Class  Library              ||     6.4   Ontology   . . . . . . . . . . . . .    10
!                     Source  . . . . . . . . . . .     4     |
!            2.4.7    The  Test  Driver  and  Ex-             ||     6.5   MetaType Ontology   . . . . . . .    10
!                     ample Code Root  . . . . .     4        ||     6.6   Common franework abstractions      11
!            2.4.8    Example application source    4         ||           6.6.1    Library Load  . . . . . . .    11
!            2.4.9    CoreLinux++   Documen-                  ||     6.7   Schemas And Persistence   . . . .    11
!                     tation    for    Standards,             |            6.7.1    Premise  . . . . . . . . . .    11
!                     Class  Reference,  Require-             ||           6.7.2    Overview   . . . . . . . . .    11
!                     ments, Analysis, and Design   4         ||           6.7.3    Schema Modeling . . . . .    11
!                                                             |            6.7.4    Schema Run Time   . . . .    12
                                                              |
! 3   Standard Development Process         4                  |            6.7.5    Current Restrictions  . . .    12
  Copyright  notice
  
  
  CoreLinux++ Copyright  cO  1999,  2000  CoreLinux  Consortium
! Revision  1.10 Last  Modified:   October  7,  2000
  
  
***************
*** 61,64 ****
--- 63,67 ----
  
  
+ This material may be distributed only subject to the terms and conditions set forth in the Open
  Publication License.
  
***************
*** 124,127 ****
--- 127,132 ----
  install-path/lib when you 'make  install'.
  
+ 
+ 
                                               2
  ^L
***************
*** 1003,1007 ****
                                               10
  ^L
! REFERENCES____________________________________6.6___Common_franework_abstractions___________
  
  
--- 1008,1012 ----
                                               10
  ^L
! 6___FRAMEWORKS________________________________6.6___Common_franework_abstractions___________
  
  
***************
*** 1024,1033 ****
  
  
  
- 6.7     Persistence
  
  
! There are many C++ applications that require the object instances to be saved and loaded for use
! across application or machine sessions.
  References
  
--- 1029,1236 ----
  
  
+ 
+ 6.7     Schemas And Persistence
+ 
+ 
+ 6.7.1     Premise
+ 
+ 
+ The persistence abstraction is built on the premise that the actual storage service code, that which
+ implements concrete persist services beneath the abstraction, should be intelligent enough to take
+ guidance  from  domain  descriptions  (concepts).  Said  concepts  define  the  types  to  be  stored,  in
+ addition to other information, and it is the job of the storage service to manage the data layout
+ and service execution as defined by it's implementation.
+      It is, after all, the 21st century.
+      This benefits the application developer from having to worry about the details of a particular
+ storage service, as well as having the flexibility to change persist implementations at will, or by
+ user choice.
+ 
+ 
+ 
+ 6.7.2     Overview
+ 
+ 
+ There are actually two (2) aspects to the CoreLinux++ Abstract Persist framework: Schemas and
+ Services.  This release focuses on the newly provided Schema constructs.  * Please refer to the
+ current implementation restrictions at the end of this document.
+      A Schema is an organization of concepts to model an idea. In this case, what is being modeled
+ are the types that the application will want to have made persistent.  When a schema has been
+ modeled,  it  is  then  usable  as  a  roadmap,  in  effect,  to  guide  the  storage  implementation.   For
+ example, the types may represent tables in a relational database storage service, or a file type for
+ a flat file service. It is ultimatley up to the service to decide how to "plan the trip".
+      There are two (2) workflows around Schemas and their concepts:  Model and Run.  Lets talk
+ turkey first:
+ 
+ 
+ 
+ 6.7.3     Schema Modeling
+ 
+ 
+ Schema modeling is supported through built-in services and functions of the library. All modeling
+ changes are persisted to gdbm databases, and the domain modeler need only focus on making their
+ schema correct.  While there is a tremendous opportunity for adventerous open source developers
+ to build tools around this (GUI, etc.), the library contains the fundemental capabilities to Create,
+ Request, Update, and Delete Schemas or their artifacts (concepts).
+      The example test driver (clfw/src/testdrivers/exf2) shows some of the following capabilities.
+      1. Typically, start by resolving the SchemaSponsor and creating an instance of it.
+      2. From the Sponser, get the Catalog object instance.
+      3. Create, Edit, Save, Close, Delete Schemas using the interface of the Catalog instance.
+ 
+                                              11
+ ^L
+ 6___FRAMEWORKS_________________________________________6.7___Schemas_And_Persistence________
+ 
+ 
+ 
+ 
+      4. Create Concepts and add to Schema
+      5. Remove Concepts from Schema and delete
+ 
+ 
+ 
+ 6.7.4     Schema Run Time
+ 
+ 
+ Once a Schema has been modeled, it can be used by a storage service to support the input and
+ output operations of application objects.
+      1. Like Schema modeling, the activation of persistence in an application starts with the resolving
+ and instance creation of a StoreSponser.  This can be done be either using the the StoreSponser
+ class name and resolving through the Ontology interfaces.
+      For example:
+      StoreSponsorPtr aSponsor ( StoreSponsor::castDown(getInstanceOf("MySQLSponsor")) );
+      or by walking the StoreSponser MetaClass hierarchy and testing each of the children nodes
+ until you find the one you want.  In latter releases we will have support for descriptive attributes
+ on MetaClasses to help reason with sponser types and capabilities.
+      Another way to load a Sponser would be to work in conjunction with plug-in support to dynami-
+ cally load types that are not part of the library compilation. Sounds like a job for the CoreLinux++
+ Library Load capability!
+      Note: In the above code example it presumes that someone has provided a MySQL persistence
+ implementation.
+      2. From the Sponser, get the Catalog object instance.
+      3. Create a Store (which would require identifying the Schema to be used as the roadmap).
+      4. Fetch a Store to write and read application object instances from and to respectivley.
+ 
+ 
+ 
+ 6.7.5     Current Restrictions
+ 
+ 
+ Name/Value Declarations
+      While ultimately Schemas and Concepts attributes won't be limited as to the depth or types
+ supported,  the  current  implementation  assumes  most  attributes  are  of  the  form:  Name:Value,
+ where:
+      Name is the Key data member of the Attribute and should be of type FrameworkString
+      Value is the Value data member of the Attribute and should be of type FrameworkString
+      Primary Schema Declarations
+      For schemas, the following are the recognized attribute keys:
+ 
+ 
+ Attribute  Key     :  "Name"
+ Expected  Value   :  Unique  name  for  this  schema
+ Example  :  "Franks  Schema"
+ Note  :  This  is  a  required  attribute
+ 
+ 
+ Attribute  Key     :  "Collection"
+ Expected  Value   :  The  collection  type  literal  (currently  "Array"  or  "SetCollection")
+ Note   :  SetCollection  is  safer  for  insuring  unique  name  keys,  although  as  new  collection  types  are  adde*
+  *d  it  is  really  up  to  the  m@
+ Note  :  This  is  a  required  attribute
  
  
+ Attribute  Key     :  "Location"
+ Expected  Value   :  Qualified  path  where  schema  should  be  stored
+ Note   :  This  is  an  optional  attribute,  default  is  ~/.clfw++/schemas/"Name"
+                                              12
+ ^L
+ 6___FRAMEWORKS_________________________________________6.7___Schemas_And_Persistence________
+ 
+ 
+ 
+ 
+ 
+ 
+ Attribute  Key     :  "GUID"
+ Expected  Value   :  Stringified  UniversalIdentifier  to  be  used
+ Note  :  This  is  an  optional  attribute,  default  is  the  system  will  generate.
+ 
+ 
+      with the following attribute expected to be supported in later releases:
+ 
+ 
+ Attribute  Key     :  "SchemaClass"
+ Expected  Value   :  The  Schema  class  type  literal  to  be  used  when  instantiating  a  new  schema,  this  will *
+  * be  stored  with  the  Schema  d@
+ Example  :  "FranksWickedSchemaDerivation"
+ 
+ 
+      Primary Concept Declarations
+ 
+ 
+ Attribute  Key     :  "Name"
+ Expected  Value   :  Unique  name  for  this  schema
+ Example  :  "Concept  A1"
+ Note  :  Even  though  concepts  can  be  created  for  other  reasons,  this  is  a  required  attribute  if  adding  *
+  *to  a  Schema
+ 
+ 
+ Attribute  Key     :  "Class"
+ Expected  Value   :  Stringified  UniversalIdentifier  of  the  type  that  this  Concept  defines  representation  of *
+  * to  the  storage  service.
+ Note  :  Even  though  concepts  can  be  created  for  other  reasons,  this  is  a  required  attribute  if  adding  *
+  *to  a  Schema
+ 
+ 
+      with the following attributes expected to be supported in later releases:
+ 
+ 
+ Attribute  Key   :  "Uses"
+ Expected  Value  :  Collection  type,  where  the  collection  contains  attributes  that  describe  data  types  of  t*
+  *his  object  should  reuse  the  @
+ Attribute  Key   :  "Data  Member  Name"
+ Expected  Value  :  "Concept  Name"
  
! 
! where:
! 
! 
! "Data  Member  Name"  is  the  name  of  the  data  member  that  has  been
! explicitly  identified  in  the  MetaClass  definition  of  the  entity
! being  stored.
! 
! 
! "Concept  Name"  is  the  name  of  another  concept  in  the  Schema
! (which  one  would  have  to  presume  is  the  same  type  of  the  Data
! Member).
! 
! 
! Attribute  Key   :  "Ignore"
! Expected  Value  :  Collection  type,  where  the  collection  contains
! single  string  values  that  identify  (by  name)  the  Data  Members  of
! the  Class  that  the  storage  management  should  ignore.  In
! otherword  don't  write  or  expect  to  read  from  persist.
! 
! 
! Attribute  Key  :  "Fence"
! Expected  Value  :  Collection  type,  where  the  collection  contains
! single  string  values  that  identify  (by  name)  the  Data  Members  of
! the  Class  that  the  storage  manager  should  recognize  as  an  indicator
! 
! 
! 
!                                              13
! ^L
! REFERENCES______________________________________________________________REFERENCES__________
! 
! 
! 
! 
! that  the  application  whats  instances  of  this  data  member  to  be  handled
! as  a  separate  table/file/etc.  according  to  it's  (storage  service)
! domain.
! 
! 
!      Please note that these would be considered "suggestions" that the declaration of which does
! not imply that a storage service would do anything with the information.
  References
  
***************
*** 1042,1044 ****
  
  
!                                              11
--- 1245,1248 ----
  
  
! 
!                                              14