[humanmarkup] RE: First Working Draft of HM.Requirements

[Rex Brooks <rexb@starbourne.com>]

Thanks, Karl.

All my questions are answered. Our requirements should be finished by 
March 31, 2002. I sympathize with the errors. I guess you're human 
too. I will be sooo glad when this portion of the task is finally 
done. Now all I need to do is find a way to leverage all this 
research, but I suspect something will turn up.

Thanks again.

Rex

>Rex:
>
>>  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.
>
>If you want to cite te normative documents governing the OASIS TCs you
>should point to the TC Process document at
>http://www.oasis-open.org/committees/process.shtml and the OASIS IPR
>Policy at http://www.oasis-open.org/who/intellectualproperty.shtml All
>OASIS TC must follow these policies. If you want to refer to general,
>non-normatiive statements regarding openness, etc. you can point to
>http://www.oasis-open.org/committees/
>
>>  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?
>
>OASIS TCs may, but are discouraged from, adopting standing rules related
>to how the TC operates, but these rules may not conflict with the
>normative OASIS TC Process or OASIS IPR Policy.
>
>>  ... 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?
>
>That's likely to be a question for the IP attorneys. The OASIS IPR
>Policy requires that specifications produced by OASIS TCs carry the
>OASIS copyright, which in turn gives anyone the right to use the spec
>freely. If an extension to that OASIS spec is owned by you then I
>suppose that you can control how that extension is used; but again, ask
>an attorney.
>
>>  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.
>
>Does not XML allow you to specify the character set encoding used by
>your application? Do it that way. OASIS has no policy on what encoding
>to use.
>
>>  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.
>
>I suppose that you could express your elements non-normatively in a
>number of different schema syntaxes (e.g. W3C Schema, RELAX, etc.) but
>some part of your specification needs to be normative. Pick whatever
>works best for the spec.
>
>>  In the second subsection under TERMINOLOGY we cite a reference
>>  to: http://www.ietf.org/rfc/rfc2119.txt for standard definitions
>>  of operational terms MUST, MUST NOT, SHOULD, SHOULD NOT, SHALL,
>>  etc. The question is whether we are allowed to do this, or does
>>  OASIS have an approved reference we could or should use instead?
>>  If the answer to both questions is negative, and we decide to
>>  use the actual wording of the ietf rfc memo, should we cite the
>>  source?
>
>OASIS does not have a required reference for this, but most TCs are
>using the IETF reference you cite.
>
>
></karl>
>=================================================================
>Karl F. Best
>OASIS - Director, Technical Operations
>+1 978.667.5115 x206
>karl.best@oasis-open.org  http://www.oasis-open.org
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--