OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [humanmarkup] Updated Draft of Requirements Document

Title: Re: [humanmarkup] Updated Draft of Requirements Docume
Hi Everyone,

One way or another I am now functioning close to normal *for me* and so I have made a couple of additions and deletions. I added another example to the "most widely accepted" standards definition affecting areas for which we "should" not attempt to create new specifications. Deletions were for doubled words and phrases, a common error to which I am prone. And I added underlines back where I think Rob's email client removed them.

> All,
> Here is latest updated HM.Requirements document that Rex put together.
> Rob
> -----
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request
last updated: 31March 2002
(this document describes the different requirements for the HumanMarkup specifications)

This document specifies goals, requirements, and usage scenarios for the various levels of the Human  Markup Language: HumanML Schemas (in various flavors), Data Models (Vocabularies) and others that have not reached formal discussion as of the day this document was published.


The design of HumanML is an effort to cover a rather large scope of possible applications.  This Requirements Document, addresses a number of anticipated possible complications that may occur in both pre-module and post-module design process of the standard.  This document is expected to be modified in the near future and be modularized along with the relative HumanML modules that the initiative's Editors will be assigned to build.

Finally, this document is not to be considered as normative. Although it may evolve into such, the primary purpose is to help the Initiative in its inner workings.

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 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 following terminology is used specifically for and throughout this document, without any claims of applicability outside it.


When enclosed in double quote marks, as above, it is used as a name for what the HumanMarkup Initiative aims to encapsulate into HumanML. Used thus, this term transcends reference to any single biological entity or to the collective biological species of Homos Sapiens, and is inclusive of all self- to species-conscious effort throughout our history to understand ourselves and our place in the universe.

When enclosed in double quote marks, as above, this word, means that the requirement item has been classified as an absolute requirement.

When enclosed in double quote marks, as above, this word means that it is believed by this Technical Committee that the requirement item will prove itself as absolute in the future, but has not yet been classified as such and may be overridden by another requirement.

When enclosed in double quote marks, as above, this word means that the requirement item can become a requirement in the future, but further study is needed.

(Changes in the above are believed by this straw-man author to be reasonably certain of inclusion in the final document, and the changes made are clarifications and grammatical corrections. As such, they can probably be accepted at this time (3/12/02) as being ready to replace the same section in the document that is currently posted on the OASIS HumanMarkup TC website.

Below the changes are more problematical, though still the best the author can come up with, however the need for reasonable brevity precludes adding arguments for each change. We can conduct such discussions online or in our next meetings.)

Primary and Secondary Schemata (Was: Layers and vocabularies)

This document distinguishes the Basic HumanMarkup Schema as the Primary Schema and subsequent "modules " as Secondary Schemata. Primary Schema and Secondary Schemata replace the term "layer(s)" for distinguishing between Schemata of a higher or lower domain, with all Secondary Schemata as being 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 following underlined sentence has been deleted since our entire vocabulary exists as a whole, and only various sub-groupings or divisions can be seen as modules when included in schemata specific to application areas or for specific purposes. For example, the vocabulary module is part of the HumanML data layer.  (debatable terminology.) I don't think the Human Markup Language can actually have a data layer. We inherit the XML Schema DataTypes, and it is the same for all, so we don't have any particular need to define our own subset, we need specify only what datatypes we want for specific Elements and Attributes.)

The Internet community is experiencing a proliferation of new technologies. This is causing some confusion and overlap among standards.
HumanMarkup standards "must" always be based on the most widely accepted, non-proprietary standards available. At this time this is XML, http://www.w3.org/TR/REC-xml Another example that is of specific relevance to our work are the specificatons created by the HR-XML.org Consortium for Human Resources applications related to employment of Humans by business concerns.

The Human Markup Language "should" not attempt to produce new standards in relation to informational subject or topic areas already addressed or covered by the above-referenced most widely accepted standards.

HumanML "should"  incorporate and/or provide for interoperabiity with the above-referenced most widely accepted standards.

HumanML "should" use the most effective standards, protocols and methodologies available to encapsulate what is "Human" in a well formed data wrapper.

HumanML "must" be open, which means readily available in its whole and its parts without recourse to restricted access by any criteria except where unavoidable.

HumanML "must" be non-proprietary, which means that no private ownership may be asserted over its whole or its parts and it must also be unencumbered by any pre-existing Intellectual Property Rights for its whole or any part of its specifications.

HumanML "must" be public, which means available freely and without any charge added to the cost of transmission to anyone by common means such as the World Wide Web or International Postal Services.

HumanML "must" be standard, which means that it is uniform in its whole and its parts with regard to any and all applications which make use of it.
HumanML "must" be vendor and/or platform neutral.

HumanML " must " conform to XML syntax and rules.

HumanML Secondary schemata "must" be extensible.

Terseness "should" be preferred.

Since XML is Unicode, HumanML implementations "must" support this by default and in a well-defined syntax. This section will most likely span a "syntax guidelines rule " applicable to all HumanML modules for a common syntax definition. (The author of this version does not believe that a Requirements Document for an xml vocabulary should make any mention of syntax. This is XML-defined, and subspecifications from groups such as this are not a good idea. This is outside our scope, again in this author's opinion.)

HumanML will be organized into a Primary Base Human Markup Schema and Secondary Human Markup Schemata.

The HumanML Primary Base Human Markup Schema "must" include a HumanIdentity Element that is compatible with and interoperable with the most widely accepted standards available.

The HumanML Primary Base Human Markup Schema Human "must" include or add the necessary Elements and Attributes required to build the Secondary Human Markup Schemata.

The HumanML Secondary Human Markup Schemata will include a Virtual Reality and Aritificial Intelligence Schema.

The HumanML Secondary Human Markup Schemata will include a Human Physical Characteristics Description Markup Language Schema.

Further officially sanctioned HumanML Secondary Human Markup Schemata will be added as voted by the OASIS HumanMarkup Technical Committee.

HumanML "should" be a schema independent framework. (The author of this version does not understand what this means, so it must be made understandable. What schema "should" HumanML be independent of or from?)
HumanML developers "should" have the choice of using HumanML vocabularies as stand alone XML, RDF, or other current and future schema implementations depending on the requirements of the applications. (The author of this version does not believe that Requirements for a specification ought not have anything to say whatsoever about how any developer anywhere at any time chooses to employ a specification. Statements of goals belong, in the current author's opinion, in mission statements or project tracking documents for the purposes of setting goals and checking goals.)
HumanML Schemata "should" clearly be correlated and differentiated from each other.  The unique advantages and disadvantages of each Schema implementation should be made explicit for developers to determine which implementation to use

HumanML, and the HumanMarkup.repository(See note below.) "should" take into account issues of trust, digital signatures, and privacy.
(Note: This author does not believe that we should, at this time, make requirements about any entities that are not yet fully included in the scope of HumanML, and the HumanMarkup.repository is such. As such, it will need to have its own Requirements Document Process, in this author's opinon.)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC