OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [humanmarkup] Base Schema - global attributes,attribute groups and datatype definition(s)


Title: Base Schema - global attributes, attribute groups and
Hi Everyone,

Since this is the last of the work for our first pass through the strawman toolkit HumanML Schema Len worked up for us last year, I want to take care of it now and ask Rob to post our list of new elements, and the new set of global attributes which Ranjeeth proposed--humlComIdentifierAtts, which I would like Ranjeeth to fill in with specific attributes and datatypes for values (I think he may want to change the attribute group name to humlComAtts since humlIdentifierAtts stands for ALL element names, and ComAtts is just for communication types, which I would like to see retricted to clear accepted types like: statement, question, bodyGesture, faceGesture. I still think this may be confusing and that each of these ought to be better dealt with in the Secondary Base Schema as signTypes, but we can discuss it. Mainly I just want it to be thought through, and not thrown out off the cuff so to speak. We don't have time to switch horses here and we will ALWAYS come up with last minute thoughts which give rise to anxieties that maybe we missed something. THAT's what the method for adding and changing the specification to be included in a new version of the HM.Requirements documents will do for us.

When I construct the html and the Word documents to accompany the .xsd file which will constitute our official namespace when approved, I will do my best to make these structural divisions (global attributes especially) easier to distinguish than currently. (Len, there's a question for you at the end of this message. If you can answer, fine, if not, also fine--I'm just lazy and there is a lot of work to do.)

Onward:

global attributes

We currently have 6 global attributes that all take (as do our elements) one set of dataypes. I will separate them by horizontal rules in the individual discussions. Even though it is an oversimplification of XML Datatypes, I use the usual association of name-value pairs to stand for the value spaces of the attributeGroupsThe 6 global attributes are:

age,
bodyPart ,
gender,
humlIdentifierAtts,
intensity,
physicalDescriptors.


Age is an attributeGroup defined as a set of attributes for documenting or determining the age of a human. This set of attributes contains two name-value pairs:
dateOfBirth takes the datatype: xsd:date and use is required
dateOfDeath takes the datatype: xsd:date and use is required

The only question I have with regard to Age is whether or not we want to annotate it to make clear that for a software agent acting as a human, these xsd:date values correspond to date of creation, or first instatiation and date of destruction.


bodyPart is a simpleType takes the datatype: xsd:string
This the list of specific string enumerations at present:
arm,
leg,
head,
neck,
hands,
feet,
finger,
toes,
eyes,
mouth,
lips
teeth,
tongue,
ear,
earlobe,
nose,
chest,
pelvis,
buttock,
thigh,
ankle,
penis,
vagina,
rectum,
nostril.

The only question I can see with bodyPart is the same one Len included, in slightly different words, as to whether we wish to compile an exhaustive listing or refer to some other standard. I don't have an opinion on this. We are going to be doing an exhaustive listing and will include set of references to other standards or lists in the Human Physical Characteristic Description ML.


Gender is an attributeGroup defined as a set of attributes for documenting the gender of a human.
This set of attributes currently contains three name-value pairs:

genderAtBirth takes the datatype: xsd:string and use is optional (default)
currentGender takes the datatype: xsd:string and use is optional (default)
impersonator takes the datatype: boolean and use is optional (default)


Human Identifier Attributes is is the full name for humlIndentifierAtts.
humlIdentifierAtts is an attributeGroup uded for indentifier uniqueness and huml element names.
This set of attributes contains two name-value pairs:
id takes the datatype: xsd:id
humlName takes the datatype: xsd:string


Intensity is defined as a single attribute which stands on its own as a specific kind of attribute that is used by many different elements. It is used to set a relative scale of the intensity or strength of some emotion or behavior.

intensity takes the datatype: range
range is defined separately.


Physical Descriptors is an attributeGroup defined as a set of attributes fpr a physical description of a human.  This set of attributes currently includes seven name-value pairs:

height takes the datatype: xsd:string and its use is optional (default),
weight takes the datatype: xsd:string and its use is optional (default),
race takes the datatype: xsd:string and its use is optional (default),
hairColor takes the datatype: xsd:string and its use is optional (default),
eyeColor takes the datatype: xsd:string and its use is optional (default),
build takes the datatype: xsd:string and its use is optional (default),
scarsMarksTatoos takes the datatype: xsd:string and its use is optional (default),

This set of attributes will need to be explicitly associated with various existing standards and the namespaces, if any, to which those standards refer. In that sense it will need to belong with the elements name and address in the set of elements so specified. These standards include authentication, HR-XML, CIQ, and public safety/law enforcement. In this sense, this particular attribute group is slightly set apart from bodyParts and the Human Physical Characteristics Description ML we will be bulding in the future.


There is currently one Datatype we define that is not part of the Built-In Datatypes
( http://www.w3.org/TR/xmlschema-2/#built-in-datatypes )

range

dt base: xsd:decimal
range [0, 1]

This specifiies a positive decimal value between 0 and 1 for establishing a value for the relative strength of an element in which it is used.


This is pretty much the extent of the strawman. I admit I haven't yet given this as much thought as I would like, but I must leave that with you all for the moment. We can discuss this thread further as you like. However in the meantime I hope Rob finds time to post the new elements and the new attribute Group, and we can start taking that up soon.

Ciao,
Rex


Len, if I could ask, (rather than spend the time to search the archives for the answer which is there, I am sure), could you tell me which graphical editor you used to create the toolkit? While it has some features I like, I will probably prefer to simply write the html from scratch or adapt the OASIS template (not required but recommended--but which, oddly is vanilla html as opposed to an XHTML, which can only be had from an XML version put through an .xsl engine with which I am equally non-plussed) unless the editor is a freebie and I can find ways to get it to behave the way I want, at least to get me to the point where I can massage the raw file. Jeez, I would hate to work for me.




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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC