Re: [humanmarkup] Base Schema - personality

[Rex Brooks <rexb@starbourne.com>]

Oops. I forgot to mention that this element shares the attribute 
group humlIdentifierAtts. I tend to take that for granted, but with 
the introductin of a possible new attribute group for communication 
elements, I better, and we better, be a bit more careful about this.

Ciao,
Rex

At 6:17 AM -0700 9/19/02, Rex Brooks wrote:
>Hi Everyone,
>
>The hits just keep coming.
>
>personality
>
>This is a ComplexType element with the abstract attribute. It is 
>described/defined as Human Personality Type used for personality 
>modeling. It does not reference other elements and is not used by 
>other elements.
>
>Provisionally, I am not inclined to make additions to the 
>description/definition of this element in the Primary Base Schema, 
>and that is a decision that I may end up recommending for the entire 
>Primary Base Schema on the basis of workability or useability 
>purposes. I think that, as with several other elements we have 
>discussed and given thought to, this one also needs to be kept down 
>to the simplest definition in the Primary Base Schema.
>
>Now, having said that, I am also beginning to think that the 
>Secondary Base Schema may want to be broken down into specific 
>application area sections where elements like this one can be 
>grouped with similar elements (such as emotion in this case) for the 
>purpose of enumerating the secondary systems that are part of such 
>elements. In this case, we have two personality typing systems, The 
>Enneagram and the Meyers-Briggs classification systems which will 
>need to be accommodated in that enumeration.
>
>So for now, I am not going to suggest that we include the 
>enumeration, or code lists, in the Primary Base Schema, except, of 
>course, for the global datatype attributes, which I think we need to 
>have in the Primary. Also, I don't want to get ahead of ourselves in 
>considering a further breakout or breakdown or hierarchical tree 
>structure for such enumerations, but I suspect that is what we will 
>want to do in separate documents in order to maximize the 
>operational efficiency of applications which use our schemata.
>
>Ciao,
>Rex
>--
>Rex Brooks
>Starbourne Communications Design
>1361-A Addison, Berkeley, CA 94702 *510-849-2309
>http://www.starbourne.com * rexb@starbourne.com
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com