[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [humanmarkup-comment] Re: [humanmarkup] Updated DraftofRequirementsDocument
Hi Guys,
Here are my responses, using the <ranjeeth> tags instead to designate my
second round of revisions. It's getting a bit messy, but still
readable.
*****
Ranjeeth Kumar Thunga
*****
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
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 evolve into such, the primary purpose is to help the Initiative in
its inner workings.
<ranjeeth>'inner workings' sounds a bit awkward. However, I can't think
of a replacement so we could stick with it (unless you guys find a
better phrase).</ranjeeth>
----------------
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.
<me>"This term refers to any anthopormorphic biological entity", would
be a more parsimonious description, and less 'out there' (although the
current definition is interesting to say the least!).</me>
<rex> We need to keep this term available to define "Human" entity and
"Human" activity. I would rather just remove the underlined explanation
and leave it rather than start confusing what "Human" refers to by
requiring an "anthropomorphic biological entity" qualification. What
happens to an AI agent that I want to give "Human" abilities and
rights/perogatives to? What is religion if not a "Human" activity?
Remember the big H small h debates? </rex>
<ranjeeth>How about 'an entity we assign anthropomorphic qualites to'.
It doesn't necessarily have to be biological. However, whatever we
refer to has to, whether real or virtual, has to imbibe 'humanlike'
qualities, such as rights, perogatives, and religion.</ranjeeth>
"Human"
When enclosed in double quote marks as above, with an initial upper case letter as written, is used as a name for the overall collection of characteristics that HumanMarkup initiative aims to encapsulate into HumanML.
"human"
When enclosed in double quote marks as above, with an initial lower case letter as written, is used as a name for a discrete anthropomorphic entity, usually, but not exclusively in reference to a presently living individual human being.
<ranjeeth>
"Developer"
The term used to describe a developer, engineer, or programmer who
builds application that utilize HumanML.
"User"
The term used to describe a consumer of HumanMarkup applications.
</ranjeeth>
"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.
<me>
"Will"
When enclosed in double quote marks, as above, this word means that the
requirement item is planned to be implemented in the future, but simply
hasn't been done yet.
</me>
I think this redundant. What does it add that "May" doesn't cover?
<ranjeeth>"Will" probably is a bit redundant, but it carries much more
certainity than "may" does. Regardless, "will" is currently used within
our current requirements document. Thus, either we have to define it
here, or we have to change many of our statements below. I say we add
the term.<ranjeeth>
<snip/>
----------------
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.)
<me>What do you mean by having no need for a 'data layer'?</me>
<rex>I mean that it doesn't belong in requirements. It's a given and it
comes from XML itself. We don't need to restate the obvious unless we
are going to make some kind of change in a given.</rex>
<ranjeeth>I'm still not too clear on what is meant by 'data layer'.
Could you provide an example?</ranjeeth>
----------------
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 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.
<me>A differentiation between the 'standards' we are based on, and the
'standards' we are creating. Additionally, we would have to distinguish
between 'latest' and 'most widely accepted' standards (they aren't
always the same, and different situations would require us to go with
one or the other.)</me>
<rex>I disagree. I said "...most widely accepted, non-proprietary
standards available", nothing about "latest." Let's vote.</rex>
<ranjeeth> Ok, here are four separate areas. Different situations would
call us to pick different choices among the following standards which we
will base HumanML on top of.
widely accepted VS.
latest VS.
most feature rich VS.
most parsimonious
I think we "should" be cognizant of all these different choices rather
than settle on any of them.
</ranjeeth>
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.
<me>"The Human Markup Language "should" not attempt to produce new
standards which significantly overlap the functionality offered by the
above-referenced most widely accepted standards."
(this might be slightly more clear)
<me>
<rex>I'd rather leave it simpler with clear examples rather than add
more words which I don't think clarify the concept. Why add new areas
for differences in interpretation? Let's keep it as simple as we can. It
is going to get complicated enough in very short order.</rex>
<ranjeeth>Your version of the sentence was a little unclear to me, while
my sentence has more jargon. How about this:
"The Human Markup Language "should" not attempt to produce new standards
which significantly overlap the functionality of currently established
standards."
(note: It "may" overlap the content or subject areas, however.)
</ranjeeth>
The Human Markup "should" not attempt to produce new standards for the above-referenced, most widely accepted standards.
HumanML "should" incorporate and/or provide for interoperabiity with
the above-referenced most widely accepted standards.
<me>'interoperability' spelling is off.</me>
<rex>?</rex>
<ranjeeth>'interoperability' is spelled wrong.</ranjeeth>
HumanML "should" use the most effective standards, protocols and
methodologies available to encapsulate what is "Human" in a well formed
data wrapper.
<ranjeeth>"data wrapper" probably needs a description or an
example</ranjeeth>
----------------
REQUIREMENTS:
----------------
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.
<me>"Comments, feedback, and contributions "must" be provided in an
forum open to anyone with email and telephone and/or IM access." This
may be an additional requirement, or an appending to the one above.</me>
<rex>No immediate preference. </rex>
<ranjeeth revision="2">"Comments, feedback, and contributions to
HumanML's development "must" be provided in an forum open to anyone with
email and telephone and/or IM access."
</ranjeeth>
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.
<me>An added statement tying into OASIS's IPR may be explicitly stated,
because HumanML is intimately intertwined with OASIS.</me>
<rex>let's allow OASIS to get itstwo cents worth in on this one. It'll
make em feel better and it doesn't hurt us to leave it open to their
participation in asserting their ownership, if they want or feel they
need to--and it gives us some information on when and/or if they are
paying enough attention to us for it to make a difference. But, in
reality, I don't think it is needed. It is a another given. (see above).
<ranjeeth>Certainly I do think it is important to get OASIS's direct
contribution on this.</ranjeeth>
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.
<me>'Publically available' may be a better term.</me>
<rex>No immediate preference.</rex>
<ranjeeth>The burden of requiring IPS access is more than I/you/we of us
can commit to. I think Internet capabilities are sufficient, especially
since HumanML is after all an Internet based standard. However, we can
extend delivery means to email, FTP, and 'HTTP'.
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.
<me>'Consistent' is a better word, since the use of the word 'standard'
may be confused with the 'standards process'. </me>
<rex>ok</rex>
HumanML "must" be vendor and/or platform neutral.
----------------
COMPATIBILITY:
----------------
HumanML " must " conform to XML syntax and rules.
----------------
EXTENSIBILITY:
----------------
HumanML Secondary schemata "must" be extensible.
<me> HumanML Secondary schemata "should" be extensible enough so that
developers can represent the human traits and characteristics they
choose to represent</me>
<rex>I strongly favor "must" rather than open the door to proprietary
modules being spun off because it needs to be understood that as long as
the process is open, it is going to be extended outside the aegis of
OASIS.</rex>
<ranjeeth> HumanML Secondary schemata "must" be extensible enough in
order to represent human traits and characteristics the developer
desires to implement.
</ranjeeth>
<me>HumanML Secondary schemata "should" be able to customize the schema,
if they so wish, based on their own unique needs.</me>
<rex>Same as above.</rex>
<ranjeeth>I actually take back my statement totally. The reason I do
this is because I realize that developers should not be able to
customize HumanML itself. This actually defeats the very purpose of
having a schema or specifications in the first place. The function of a
schema is to constrain data, rather than allow unlimited
customizability.
*NOTE: In this case, I regard customizability as being different
concepts from either extensibility or modularity. Subtle but important
distinction.
</ranjeeth>
Terseness "should" be preferred.
<me>'sought', rather than 'preferred'.</me>
<rex>duh? I don't understand, I need a complete sentence. I don't know
how you want to construct the statement you prefer.</rex>
<ranjeeth>Terseness "should" be sought. ('Preferred' is not appropriate
because there is nothing for it is preferred against.)</ranjeeth>
----------------
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.)
----------------
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?)
<me> "schema independent" refers to a having a layer of abstraction
between the XML Schema or RDF implementation, and the conceptual
framework itself</me>
<rex> I still don't understand. Independent of what? from what? I don't
know what having a layer of abstraction means nor what it has to do with
Schema Independence. Maybe I'm dense. Maybe someone else can explain it
to me in terms more concrete or maybe you can give me an example. If I
don't understand it, I can see what it accomplishes for us.</rex>
<ranjeeth>Schema independent means independent of the XML vocabulary
used.....kinda like the original Class diagrams you had created last
year, or the HumanMarkup frameworks document we (mainly you) worked very
hard on.</ranjeeth>
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.)
<me> How about should _be able_ to have the choice. As designers of the
schema, we would ensure that the choice to implement any or all of the
HumanML vocabularies is available.</me>
How does having this in our requirements document give them/us a choice?
We are not requiring anyone to use HumanML as standalone or dependent or
combined, or anything, as far as I know. That which is not required is
optional, therefore, the choice is there. We don't need to put in a
requirement.
<repeat>This is good debate. I hope more people jump in immediately.
This is what we need to do before we get to Wednesday's
meeting.</repeat>
<ranjeeth>We have to guarantee that when building our modules, we don't
lock down any patterns obligating users to use certain components. I
can draw a parallel in real life. In an Intro to Computers class I
taught, I had a student who had 20 years experience in the field.
Although he knew more about the course material than I myself did, he
was obligated to take this course because it was part of his package.
In the same vein, although we may end up having several packages, we
have to ensure we don't box anyone in.
</ranjeeth>
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
----------------
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, 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.)
Thanks,
Rex
--
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC