[humanmarkup] First Working Draft of HM.Requirements

OASIS ITEM 1: Under PROCESS REQUIREMENTS section, we chose to specifically state compliance to and so to emphasize our commitment to these policies. Do we need to cite a specific document or set of documents for these policies? Is it assumed that any and all TCs follows these policies? Does this TC need or is it allowed to make explicit statements about policy with regard to 'openness,' 'public v. publicly available,' considerations? This relates to soliciting feedback from developers and users in a public forum.

OASIS Iterm 2: In regard to IPR, can a TC set further restrictions or constraints upon its processes or the use(s)/extension(s) of its specifications? In other words, can OASIS specifications be extended in proprietary applications which exclude further uses of the OASIS specification which also include the proprietary application or results from use of that application?

For example, can someone take a HumanMarkup Specification, add proprietary methods or operations that result in a perfectly valid xml extension--by xml rules--thereby creating results for which they can charge or prohibit the use of such extended alterations to, for example, any individual's HumanML-based preferences profile?

Are there any such examples from other TCs?

OASIS Item 3: In considering the implications of XML policy with regard to Unicode, we pondered a requirement for compliance with it, but decided against it since it is not within our scope, but since we have a great interest in making HumanMarkup independent of cultural and language biases, we would like to know if OASIS has a policy about this to which we can refer to which we can stipulate.

OASIS Item 4: We would like to make HumanMarkup independent of any specific xml schema or DTD, even while we seek to be interoperable with the widest possible application base. One way to do this, and to prevent any vocabulary conflicts with related schemata or specifications would be for all elements and attributes we specify to contain a prefix specfic to the term, and also covered by an official glossary contained in our namespace(s). Thus all HumanMarkup Elements would be in the form huml.ElementName. Since this sort of mechanism could be applicable to all OASIS specifications, we need to know if this is allowable or advisable.

End of OASIS-specific concerns and questions.
------------------------

This is the first Working Draft of HM.Requirements based on the process the OASIS HumanMarkup Technical Committee adopted for this purpose. This marks the transition from the requirements-gathering phase of our initial work to the specifications-writing phase.

This draft was based on the detailed discussions of the latest strawman draft including submissions to date held during the monthly meeting of the TC held March 20, 2002 by teleconference. I needs to be proofread for typographical and grammatical correctness as well as for technical considerations.

**It is also noted that we do not have, and have not discussed any need for an introduction. Therefore, some passages are included which cite guiding principles from our TC charter, such as making reference to and specifying focus upon communication and the imperative to include the means to enable cultural modules in our base schema.**

A decision to include a short introduction would not, in this interim author's opinion necessitate removing those short sentences. This author, also, does not think an introduction is necessary, but notes that many other such documents do include one, though most have some informational purpose beyond simply stating objectives.

Two items were added or amended by the interim author, the TC Secretary Rex Brooks, and are his responsibility. The reasons are given here after the citation. There are numerous other small changes, and a great many deletions of material disclaiming the interim status of previous drafts that no longer apply. I mention that because we did not specifically cover that in our meeting.

Item 1: Under the PROCESS REQUIREMENTS section, the name was changed, adding the word PROCESS, to distinguish these particular requirements from the stipulations of the entire document, and the following paragraph was added in the belief that this was the guiding principle by which we included the terms DEVELOPER(S) and USER(S) to the TERMINOLOGY section, and it is not specifically covered by the OASIS guidelines and policies.

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

Item 2: Under the MODULARITY section, the Element Name: HumanIndentity was reverted to: HumanIdentifier because that was the term used in the Phase 0 Toolkit Schema, and there seemed to be no need to change that. An addition was added to note that the TC may add more standards for which compliance will be required in order to ensure that all modules created from this Element or with this Element will be widely interoperable. It now reads:

The Primary Base HumanML Schema MUST 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.

**Note: some of the possible conflicts of vocabularies between or amongst these overlapping specifications and standards would be eliminated by the universal practice of putting all HumanMarkup Elements and Attributes in the forms: huml.ElementName and huml.AttributeName, or in this case, huml.HumanIdentifier.**

Lastly, the primary way in which we can ensure compatibility, compliance and interoperability is to specify the minimal number of elements and let usage and what we learn from it, determine the further development of HumanMarkup.

No doubt we will encounter numerous unanticipated concerns as we proceed.

Thanks Everyone, and please be prompt in responding. Our target is still March 31, 2002 to wrap this up.

Regards,
Rex Brooks
OASIS HumanMarkup Vice Chair, Secretary and Webmaster

humanmarkup message