If I may make a suggestion here ...
It is not uncommon for schemas to define a union of
two or more differing types, one a set of enumerations, the other a numerical
value. Thus you could have:
<happy level="0.245"/> and <happy
level="amused"/>
The specific token set for <happy> would then
run something like:
none|amused|excited|ecstatic|[0,1]
It would then be the responsibility of the
implementer to set numerical equivalences for the named tokens. This is typical
of other specifications such as CSS.
-- Kurt
----- Original Message -----
Sent: Monday, October 08, 2001 1:45
PM
Subject: Re: HM.VR_AI: Goals and Overview
: HumanML_VR_AI Facilitator
Oh For Joy, For Joy!
A legitimate disagreement, and I couldn't disagree more. We absolutely
must have numerical values as datatypes for many of our elements, particularly
the complexClass(es) which will need to deal with a spectrum of values and %
or cm or in are all human readable anyway.
The simpleClass can be smile/not smile or expression/lack of expression,
and that's one level. But smile to be useful for VR, for instance, has to be
valued or weighted as to how much of a smile it is to be portrayed as if it is
to translated to middleware thence to X3D or any other 3D file format.
BTW, it's about time we started having this kind of discussion.
Ciao,
Rex
At 4:31 PM -0400 10/8/01, Ranjeeth Kumar Thunga wrote:
BTW, thanks very
much Rob for this proposal document. This can help us piece together
lots of the information we've been discussing related to VR and AI
topics.
What I feel as an
important litmus test to 'where HumanML' belongs amongst
other processing and rendering languages is that the
element/attribute values are to human
readable.
For example,
<happy level=".434"/> would not be acceptable, whereas <happy
level="ecstacy"> might be. Or <smile width="53%"/> may not be
acceptable, but <smile width="5in"/> would be, or perhaps <smile
width="wide"/>.
This would very
importantly apply to proxemics and chromemics.
This ensures that
HumanML values are in fact, what we as humans use, matches its stated
purpose of not being an interface on the 'human' layer, not layers
below. Regardless, mappings between machine sensible
markup, and human sensible markup, could be formally and explicitly
described in code, or either custom or standard XSLT.
Ranjeeth Kumar
Thunga
----- Original Message -----
From: Rex
Brooks
To: Bullard, Claude
L (Len) ; rnixon@qdyn.com
Cc: OASIS
Comment
Sent: Friday, October 05, 2001 7:02 PM
Subject: RE: HM.VR_AI: Goals and Overview :
HumanML_VR_AI Facilitator
Sorry, part of that was my contribution and the two parts of
sentence didn't marry up completely. the structured approach refers to our
use of xml and rdf schemata in our primary work, and our ongoing
investigation of EMOTE work and Project Oz and Perlin's work, and now
Rob's work in AI such that they tell us what requirements they need and we
see if we can accommodate it or at least not create outright contradictory
vocabularies. These bridges are the middleware which will use HumanML to
do work with the lowerlevel languages like X3D/h-anim with and apart from
MPEG-4 and SMIL and SOAP and OIL.
Is that a little more clear?
Ciao,
Rex
At 2:56 PM -0500 10/5/01, Bullard, Claude L (Len) wrote:
I
don't understand the following. Please
clarify:
"To be prepared for this, we are establishing
a structured approach to provide for making HumanML readily useful for
applications that bridge the "real" and "virtual" worlds can experience
a potential imbalance in available attributes, and it may be necessary
to provide a mechanism to adjust the mapping of attributes from the
virtual to the real. "
Also note that both chronemics and proxemics
have scale issues. Personal real time and historical
time have their analogues in spatial dimensions which
include
both personal space and geographic
space. In the case of proxemics, I anticipate the use of concepts
and data objects from the Geometry Modeling
Language
for position-dependent services involving
geometric space.
len
--
Rex
Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA,
Earth W3Address: http://www.starbourne.com Email:
rexb@starbourne.com
Tel:
510-849-2309 Fax: By Request
--
Rex Brooks GeoAddress: 1361-A
Addison, Berkeley, CA, 94702 USA, Earth W3Address:
http://www.starbourne.com
Email:
rexb@starbourne.com
Tel: 510-849-2309 Fax: By
Request
|