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] Short notes in reply to Re: Good draft. NOTES: onHumanML Requirements doc draft2,


Title: Short notes in reply to Re: Good draft. NOTES: on Huma
Thanks Sylvia,

To everyone, I am posting this with Sylvia's entire post for the record, and request that any comments be addressed to the list and not to me personally. No offense. Just policy. We need to keep our public record of discussions public.

I will post my version of draft 2 sometime Monday or Tuesday. I INCLUDE ONLY SYLVIA's POST BELOW THE HORIZONTAL RULE UNDER MY COMMENTS. I will include any further discussions in that draft, and we can continue discussions on the humanmarkup-comment list and vote on the TC list later in the week, or have another quick chat or telecon, if we have time. Wednesday Noon EST would be best for me.

Just a few quick replies. I will probably include most corrections as they are needed. So I will only mention the ones which I have some clarification to ask or make.

Under TERMINOLOGY P5: I think you may have thought I meant rules other than lines as graphic objects to demarcate the two sections under TERMINOLOGY. All lines that consist of a series of hyphen characters represent graphic rules. I should have made that clear. I adopted this technique, adapting it from a practice used by Ranjeeth in earlier versions of these documents because it will be fairly easy to construct an XSL document to transform all of our documents from plain ASCII text to XHTML if all of these elements which are separate lines now, can be transformed into horizontal rules.

Under TERMINOLOGY P8: I made MANKIND in your suggestion "humankind" because I am perhaps an overcompensating recovering sexist, but mainly because I am sensitive to it from having been raised in a sexist society without questioning it, and it is the "without questioning it" part that continues to sting me. Also, for some personal reasons I won't mention I am constantly having my nose rubbed in those ingrained social values from the late 30s,  40s and  50s in WASP midAmerica, which is rather tough on a non-deist zenTaoist marginally cherokee Amurikan caucausoid. However, I meditate a lot and that helps. ;)

In TERMINOLOGY P9, I included [sometime-] and "else," but left out the" representing" or "acting in combination with," because the former is incorrect and the latter is subsumed. An AGENT receives exactly the same rights and privileges as a livng human being. We don't want to complicate this that much. To a machine it makes no difference if an entity is a real human being or not. Also to a machine there is no "mixed Computer-Human" environment. All it can see is binary data with some authentication information that meets or fails its criteria algorithm for access. It is up to the apps builders to put in those other kinds of constraints and we can only enable or disable those constraints based on how we build HumanML.

This point could use more discussion.

Under COMPATIBILITY P2: No, the The is not part of the title of the TC, and I have made the correction to lower case "the."

Under MODULARITY P2: I agreed with you and remembered to put the last "should" into all caps ...SHOULD be compatible with and interoperable with these standards and recommended practices.

Note: Gee, I told Ranjeeth I was going to go back to a second day off today, especially after having received word that our support corporation received its official Non Profit 501 (c) (3) status!

But look what happened. Is there a 12 step program for workoholics. DON'T even think about it!

Ciao,
Rex

Sylvia's proofing and corrections:

X-Sender: cognite@zianet.com
Date: Sat, 23 Mar 2002 15:57:52 -0700
To: rexb@starbourne.com
From: cognite@zianet.com
Subject: Good draft. NOTES: on HumanML Requirements doc draft2,
X-Rcpt-To: <rexb@starbourne.com>
X-DPOP: DPOP Version 2.4a
Status: U


NOTES: on HumanML Requirements doc draft2, 23March 2002, S. Candelaria de Ram
- Document seems near-final now.  Notes below only where [minor] change
might be wanted. 
- Section headings retained for reader's ease in following notes. 
- ENTIRE doc WITH CHANGES follows after ======= delimiter line, for use with
diff operator if desired.

HM.REQUIREMENTS

----------------
ABSTRACT:
----------------

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

P1: comma at option.

P2

----------------
TERMINOLOGY:
----------------
P1

P2: "= the XML-based, special-purpose computer networking language specification
<-  = the XML-based computer networking language specification

P3

P4

P5: provide <- mark the end of the, hyphenation of compound-word adjective  --
The rules below provide definitions of general-use terms HumanMarkup terms.
----------------
----------------
P6

P7  AND "OPTIONAL" in this document <- AND "OPTIONAL" is this document

P8: insertion to avoid tautology, of:  Mankind, i.e., ->
HUMAN
When all in capital letters, as above, this term is defined as what the
HumanMarkup Initiative aims to encapsulate into HumanML. Used thus, this
term applies to Mankind, i.e., HUMAN individuals, HUMAN thought, HUMAN
activities.

P9: change to allow reference to beings of future and past via insertion
of [sometime'], and to mixed Computer-Human systems via: else ... as or in
combination with;

"human"
When enclosed in double quote marks without capitalization, as above, this
term is defined as an individual entity that may represent in a digital
environment a [sometime-] living human being with the rights and privileges
granted to a "human" or else represent a software AGENT acting as or in
combination with a "human."

P10: typo, encompass sing./pl.

DEVELOPER(S)
When capitalized, as above, this term is defined as being software
developer(s), software engineer(s), or software programmer(s) who build an
application that utilizes HumanML.

P11: sing./pl.

USER(S)
When capitalized, as above, this term is defined as referring to one or more
consumer(s) of HumanML applications.

P12: phrase juxtaposition

Note: Unless specifically stated otherwise (as in "RDF Schema"), the word
'schema' in all of its variations refers to XML Schema because this work is
intended as an XML extension.

----------------
CLASSIFICATION:
----------------
Primary and Secondary Schemata

P1: moved equal footing description to later paragraph

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

P2: change of descriptor of our solution to be one among all possible
solutions via determiner: definite the to indefinite a

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

P3: Primary...contain [FEATURE GROUP] from which...Schemata can be
formulated as extensions. <- contain x
from which y can be extended.

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.

P4:

P5:

P6

P7:  List looks good!


----------------
EXISTING STANDARDS:
----------------

P1:  addition of contrast with 'but':

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

P1

P2: usability <- useability

When and where possible, feedback from DEVELOPERS and USERS SHOULD be sought
to improve the usability of all HumanML specifications.

----------------
COMPATIBILITY:
----------------
P1

P2:  Is the The part of the TC title?

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



----------------
MODULARITY
----------------
P1: repetition of linking 'with' to clarify relation of second object

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.

P2:  Our intent is to make them interoperable if possible.  But if not
possible, our work still will have validity.  Is it adequate to change 'MUST
include'
to 'MUST be designed to include'?

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



============================================================================
===========
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 general-use terms
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" is
this document are to interpreted as described in RFC 2119. ref.:
http://www.ietf.org/rfc/rfc2119.txt

HUMAN
When all in capital letters, as above, this term is defined as what the
HumanMarkup Initiative aims to encapsulate into HumanML. Used thus, this
term applies to Mankind, 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 that may represent in a digital
environment a [sometime-] living human being with the rights and privileges
granted to a "human" or else represent a software AGENT acting as or in
combination with a "human."

DEVELOPER(S)
When capitalized, as above, this term is defined as being 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 referring to one or more
consumer(s) of HumanML applications.

Note: Unless specifically stated otherwise (as in "RDF Schema"), the word
'schema' in all of its variations refers to XML Schema because this work is
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.

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.

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