[humanmarkup] Short notes in reply to Re: Good draft. NOTES: onHumanML Requirements doc draft2,

[Rex Brooks <rexb@starbourne.com>]

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.

--