[humanmarkup] Latest draft of HM.requirements

[Rex Brooks <rexb@starbourne.com>]

Hi Good People,

I have attached the latest version of the working draft of 
HM.requirements.txt without a Word version, sorry. I'm very busy this 
morning. It includes all of the corrections mentioned by Sylvia, 
minus the specific ones which I had differences with and which I 
wrote about. I suggest you open it up in a word processor. You may 
also be receiving the message I sent to Karl Best this morning 
concerning the paragraph I added to the PROCESS REQUIREMENTS section. 
Please read both and review the docuement. I will be calling for a 
chat/telecon this afternoon for tomorrow and a vote on Sunday or 
before. (Note that no dissent will cause a possibly flawed version to 
be approved, so please do double check my work.)

Please note that the paragraph as written is not in the MUST, MUST 
NOT category of requirement yet. That is why I stated it as a 
reservation of the right to include such a stipulation at a later 
time. Since we can amend it later on, I did not want to add such a 
potentially controversial statement in this version at this time. In 
general I would oppose such language, but I recently had to do 
exactly what I describe in order to listen to an mp3 file from a 
friend who does not have the bandwidth to upload a full .wav or .aif 
file of the full waveform, which is what I prefer for such files. It 
made the point plain to me, and it reminded me that I recently had to 
remove IE 6 from my systems because they degrade performance of Non 
MS applications of which I have many. Rational and IBM and Oracle do 
the same, but don't hook into the system so completely that the 
entire machine performance bogs down, so i only have problems based 
on those app suites while I am actually using them. Under NT I had to 
have separate regedits for app suites and I have been attempting to 
avoid that registry nightmare with 2K and XP, though it is looking 
like I am going to be pushed into resorting to that huge timewaste 
yet again.

How I love Windows, let me count the ways.... I have a new set of 
problems with OS X on the Mac Platform, but that is another 
discussion.

And, please note, in my message this afternoon/evening, I will be 
recommending a couple of procedures which I believe we need to adopt. 
I have to actually write them out and work it down to something as 
simple as I can first. And, as I said, I'm busy.

Ciao,
Rex


-- 
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 such 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.