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: [humanmarkup] Re: Question


Here is a corrected version. I would have sworn that I cut the 
MULTIPLE IMENTATIONS Section and then pasted it in the correct place, 
but evidently I simply copied it and then pasted it twice. Thanks for 
catching it, Rob. There is a study from Stanford Research Institute 
that shows that most people, but men more than women, think they are 
getting more done by multitasking, but that they (we or ME) are 
simply performing more poorly. I believe it.

ciao,
Rex

>Rex,
>
>Am I missing something.  I think the MULTIPLE IMPLEMENTATIONS: section
>is in the document 3 times.   Is this a mistake?
>
>Also, under requirements, second paragraph I after (HumanML"must" be )
>you have "inon-proprietary"
>
>
>Hope this helps, thanks for posting the doc.
>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
HM.REQUIREMENTS
last updated: 31March 2002
(this document describes the different requirements for the 
HumanMarkup specifications)
---------------------


----------------
ABSTRACT:
----------------
This document specifies goals, requirements, and usage scenarios for 
the 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.

----------------
DOCUMENT STATUS:
----------------

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 involve into such, the primary purpose is to help the 
Initiative in its inner workings.

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

"Human"

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.

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

"Should"
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.

"May"
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.)

----------------
CLASSIFICATION:
----------------
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.)

----------------
EXISTING STANDARDS:
----------------
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

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.

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

HumanML "must" be inon-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.

----------------
COMPATIBILITY:
----------------
HumanML " must " conform to XML syntax and rules.

----------------
EXTENSIBILITY:
----------------
HumanML vocabularies "must" be extensible.

Terseness "should" be preferred.

----------------
INTERNATIONALIZATION:
----------------
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.)

----------------
MULTIPLE IMPLEMENTATIONS:
----------------
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 Schemas "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.

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

----------------
MULTIPLE IMPLEMENTATIONS:
----------------
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 Schemas "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

----------------
MULTIPLE IMPLEMENTATIONS:
----------------
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 Schemas "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

----------------
TRUST/DIGITAL SIGNATURES:
----------------
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 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