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.