[humanmarkup] HM.requirements up for vote plus notes and thoughts.

[Rex Brooks <rexb@starbourne.com>]

Hi Everyone,

The last version of HM.requirements which I am attaching to this post 
for your convenience, is now up for a vote of the TC members. The 
vote will last until Saturday, March 30, 2002. We will announce the 
results Sunday, March 21, 2002. It is requested that members vote on 
the TC mailing list, and if you wish your vote to be known at large, 
please copy it to the public comments list.

Last evening's chat was instructive, and I will discuss it briefly. 
Ranjeeth Kumar Thunga and Rob Nixon and I attended.  Dr. Sylvia 
Candelaria de Ram was unable to connect to us by Yahoo IM, which has, 
it should be noted, been somewhat unreliable lately. She did attempt 
to connect and sent me an email to let me know. Kurt Cagle also 
attempted to attend, but was delayed by domestic complications of a 
two-year daughter nature so attempted after the session had 
concluded. Thanks to both of you.

Ranjeeth reviewed the document at the time and began the process of 
developing some rather substantial changes he felt were needed. It 
seemed apparent that this would require delaying our work in order to 
accomplish these changes, present them to the committee as whole and 
reschedule a vote on the revised document.

I noted this, and made the statement that I thought it was 
inappropriate at this stage in the process and that what I was 
prepared to do was to make typographical and grammatical corrections 
and small wording changes after this much previous work and the 
length of time that this version has been up for comment, corrections 
and changes. Rob agreed with me, and since that consitituted a 
majority, it was unnecessary to carry it further.

Ranjeeth said this was ok with him, and as I would like to point out, 
the issue is now up for a vote, so we can always start over, although 
we don't have to start from square one, but that is not what we 
decided to recommend.

After some further discussion, we decided that we would go with what 
we have and vote now. We want to make it clear that while officially 
formal if adopted, this is only a "Working Draft" and that the next 
six months will be an official RFC, Request For Comments, period if 
it is approved and thus adopted.

During these six months such concerns as Ranjeeth began developing 
last night, which simply didn't occur to him until then and really 
ought to be considered carefully, and adopted most likely, will be 
collected as as a thread in our email archives at the end of six 
months, in the normal process used by most standards organizations. 
We will meet then, decide which changes to make, make the changes we 
decide, and vote at that time for a final recommendation document. It 
should be noted that this would have been the case even if Ranjeeth 
had not started finding changes he thought we need to consider.

I have the transcript, and I will post it separately. Because it is 
lengthy, I did not want to add it to this message.

In further developments, Ranjeeth noted that he could not agree to 
combine his Diplomatic Negotiations work with HumanML_Write/Report 
and that is sufficient for me to withdraw the agenda item from our 
next meeting.

Finally, because the WSIA TC is having its second round of face to 
face meetings starting April 17, 2002 in Palo Alto, CA at the 
Hewlett-Packard Labs, it may be necessary for me to ask that our 
meeting by teleconference and Yahoo IM be changed from the same date 
to one earlier or later, but I have already requested an outside 
phone line for the hour or so that we would be meeting. Because 
Ranjeeth will be in Washington D.C. at about that same time, I 
believe, it may just be wiser to change the time of our next meeting. 
So, would April 10 work for everyone? It is a week earlier, and of 
course, 12:00 p.m. Noon EST.

Note, lack of dissenting votes will constitute approval by 
acclamation, so failing to vote is a vote in favor.

Regards,
Rex Brooks
OASIS HumanMarkup TC Vice Chair, Secretary and Webmaster

-- 
HM.REQUIREMENTS
last updated: 31March 2002
(this document describes the different requirements for the 
HumanMarkup specifications)
---------------------


----------------
ABSTRACT:
----------------
This document specifies the formal Requirements for the Base Primary 
Human Markup Language Schema, the process for revising the Base 
Primary Schema and creating the currently planned and as yet 
unplanned Secondary Human Markup Schemata.

----------------
DOCUMENT STATUS:
----------------

The design of HumanML covers a large scope of possible applications. 
This Requirements Document  is designed in the expectation that this 
document, the Primary Base Human Markup Language Schema and Secondary 
Human Markup Language Schemata, will be modified as needed.

This document is normative as of the date it is adopted by the OASIS 
HumanMarkup Technical Committee.

----------------
TERMINOLOGY:
----------------
For the purposes of clarity, we offer these definitions for terms we 
use in general and which may appear in this document but are not 
specific to this document:

Human Markup Language (compound term with separated words with Upper 
and Lower case characters as shown) = the XML-based, special-purpose 
computer networking language specification itself and all of its 
associated modules and sub-specifications.

HumanML(compound term with Upper and Lower case characters as shown) 
= the Human Markup Language Specification.

HumanMarkup (compound term with Upper and Lower Case characters as 
shown) = the collective effort to build the Human Markup Language, 
also used for similar purposes in the name of the OASIS HumanMarkup 
Technical Committee.

The rules below mark the end of the definitions of compound-word, 
abbreviated, general use HumanMarkup terms.
----------------
----------------
The following terminology is used specifically for and throughout 
this document, without any claims of applicability outside it.

When capitalized the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 
AND "OPTIONAL" in this document are to interpretated as described in 
RFC 2119. ref.: http://www.ietf.org/rfc/rfc2119.txt

HUMAN
When capitalized, as above, this term is defined as what the 
HumanMarkup Initiative aims to encapsulate into HumanML. Used thus, 
this term applies to humankind, i.e.HUMAN individuals, HUMAN thought, 
HUMAN activities.

"human"
When enclosed in double quote marks without capitalization, as above, 
this term is defined as an individual entity in a digital environment 
that may represent a [sometime-] living human being with the rights 
and privileges granted to a "human" or else to a software AGENT 
acting as a "human."

DEVELOPER(S)
When capitalized, as above, this term is defined as software 
developer(s), software engineer(s), or software programmer(s) who 
build an application that utilizes HumanML.

USER(S)
When capitalized, as above, this term is defined as one or more 
consumer(s) of HumanML applications.

Note: Unless specifically stated otherwise (as in RDF Schema), the 
use of the word 'schema' in all of its variations refers to XML 
Schema because this intended as an XML extension.

----------------
CLASSIFICATION:
----------------
Primary and Secondary Schemata

This document distinguishes the Basic HumanMarkup Schema as the 
Primary Base Human Markup Language XML Schema and subsequent modules 
as Secondary Human Markup Language XML Schemata. Primary Schema and 
Secondary Schemata represent categories for distinguishing between 
Schemata of the fundamental or extended domain, respectively. All 
Secondary Schemata are capable of engendering and containing further 
modules which can be classified as derivative or submodules as 
appropriate, but which may always be seen as existing in the 
Secondary grouping on an equal footing.

The Primary Base Human Markup Language XML Schema MUST contain the 
Elements and Attributes to describe a basic or fundamental set of 
characteristics of HUMAN entities and HUMAN activities as they occur 
in digital information systems. In keeping with the charter of the 
OASIS HumanMarkup Technical Committee, which states that the aim of 
HumanML is to "enhance the fidelity of human communication," this 
schema SHOULD specifically address the HUMAN activity of 
communication.

The Primary Base Human Markup Language XML Schema MUST contain the 
Elements and Attributes from which the Secondary Human Markup 
Language XML Schemata can be formulated as extensions. Secondary 
Schemata exist in the Secondary grouping on an equal footing.

If the Primary Base Human Markup Language XML Schema does not contain 
the Elements and Attributes from which a specific Secondary Human 
Markup Language XML Schema can be written, those elements and 
attributes necessary to produce the specific Secondary HumanML XML 
Schema MUST be added to the Primary Base HumanML XML Schema.

Therefore, a mechanism, method or means to add Elements and 
Attributes to the Primary Base HumanML XML Schema MUST be constructed 
and approved.

When this mechanism, method or means is approved, it should added here:

(Mechansim, Method or Means of Adding Elements and Attributes to the 
Primary Base HumanML XML Schema)

The specific Secondary Human Markup Language Schemata that are 
currently planned or anticipated are:

* Cultural Schemata;

* Virtual Reality and Artificial Intelligence Schemata;

* Human Physical Characteristics Description Markup Language Schema;

* Conflict Resolution and Diplomatic Communications Schemata;

* Various Schemata related to Human Profiling in terms of preferences 
and behavior tracking

* Various Schemata related to Human Psychology.

It is noted that this is a partial list only.

----------------
EXISTING STANDARDS:
----------------
The Primary Base Human Markup Language Schema will be based on:
XML 1.0, http://www.w3c.org/TR/2000/REC-xml-20001006
XML Namespaces, http://www.w3c.org/TR/1999/REC-xml-names-19990114/
and XML Schema http://www.w3.org/TR/xmlschema-1/ 
http://www.w3.org/TR/xmlschema-2/

The OASIS HumanMarkup Technical Committee SHALL also provide for an 
RDF Schema to represent the same elements and attributes of the 
Primary Base HumanML and Secondary HumanML XML Schemata but in RDF 
terms.

----------------
PROCESS REQUIREMENTS:
----------------
The Primary Base HumanML and Secondary HumanML Schemata SHALL be 
produced in accordance with OASIS principles and policies with regard 
to open, public standards processes and IPR.

For TC process requirements refer to 
http://www.oasis-open.org/committees/process.shtml

For IPR policy refer to http://www.oasis-open.org/committees/

The OASIS HumanMarkup Technical Committee reserves the right to 
require further restrictions upon the use of its recommended 
specifications for the purpose of proprietary licensing of 
applications including said specifications if said use in any way 
constrains further use of Human Markup Language Specifications. 
Specifically, we wish to make it clear that an application which uses 
a Human Markup Language Specification for any application with a 
modification that renders that or any unmodified specification 
obsolete or unusable in whole or in part SHOULD NOT be allowed.

When and where possible, feedback from DEVELOPERS and USERS SHOULD be 
sought to improve the usability of all HumanML specifications.

----------------
COMPATIBILITY:
----------------
HumanML MUST conform to XML syntax and rules.

Terseness SHOULD be sought. This is to be considered a guiding 
principle. By adopting this principle as a requirement at this level 
of commitment, the OASIS HumanMarkup Technical Committee aims to 
ensure greater compatibility through a lack of unnecessary complexity.


----------------
EXTENSIBILITY:
----------------
The Primary Base HumanML and Secondary HumanML Schemata MUST be extensible.


----------------
MODULARITY
----------------
HumanML SHALL be organized into a Primary Base HumanML Schema and 
Secondary HumanML Schemata. All Schemata SHALL be considered modules. 
All HumanML modules MUST be interoperable with each other, as well as 
with such standards as SHALL be so designated.

The Primary Base HumanML Schema MUST be designed to include a 
HumanIdentifier Element that is compatible with and interoperable 
with the U.S. Federal Government standards, standards accepted by a 
majority of Public Safety Institutions, Federal, State and Local Law 
Enforcement practices,HR-XML specifications, American Medical 
Association standards and any standards so designated by the OASIS 
HumanMarkup Technical Committee. Thus, all HumanML modules SHOULD be 
compatible with and interoperable with these standards and 
recommended practices.

----------------
TRUST/DIGITAL SIGNATURES:
----------------
All HumanML Schemata, including RDF Schemata, SHALL recognize XML 
Digital Signatures and SHALL be constructed to comply with such Trust 
and Security specifications as shall be deemed necessary by the OASIS 
HumanMarkup Technical Committee.