humanmarkup message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [humanmarkup] StrawMan Draft of Requirements Document
- From: Rex Brooks <rexb@starbourne.com>
- To: humanmarkup-comment@lists.oasis-open.org, humanmarkup@lists.oasis-open.org
- Date: Tue, 12 Mar 2002 08:14:25 -0800
Title: StrawMan Draft of Requirements
Document
Hi Everyone,
Here it is. I have also
included the document as an attachment so you don't have to copy and
paste.
Note 1: This does not include
the lists I hope will have to add in sections under the applications
areas we vote to include in our upcoming meeting(s).
Note 2: I have done the
minimum of what I could. And I have put it into the same format, for
headings and sections as all the rest of our documents which I have
updated in text-only ASCII.
Chances are we will be having
subsequent meetings before the 31st for finishing this
up.
Ciao,
Rex
HM.REQUIREMENTS
last updated: 31 March
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.)
--
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