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)
- From: Rex Brooks <rexb@starbourne.com>
- To: humanmarkup-comment@lists.oasis-open.org, humanmarkup@lists.oasis-open.org
- Date: Mon, 14 Oct 2002 11:46:21 -0700
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