[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup] HM.requirements up for vote plus notes and thoughts.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC