This is a Working Draft.
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.
If you have comments about this document, please send them to Ranjeeth Kumar Thunga rkthunga@humanmarkup.org
Copyright © 2002 The Organization for the Advancement of Structured Information Standards [OASIS]
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 be interpreted as described in [RFC 2119].
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.
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:
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.
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.
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.
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.
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.
The following individuals helped in the formulation of this document:
Copyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001, 2002. All Rights Reserved.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS has been notified of intellectual property rights claimed in regard to some or all of the contents of this specification. For more information consult the online list of claimed rights.
[RFC 2119] IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels.S. Bradner. 1997.
[XSLT] James Clark, editor. XSL Transformations (XSLT) Version 1.0. World Wide Web Consortium, 1999.
[XSL] Sharon Adler, Anders Berglund, Jeff Caruso, et. al., editors. Extensible Stylesheet Language (XSL) Version 1.0.World Wide Web Consortium, 2001.
[PDF] Adobe Systems, Incorporated, editor. PDF Reference, Third Edition, Version 1.4. Addison Wesley. 0-201-75839-3. 2001.