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] RE: 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.

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

> 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 F. Best
OASIS - Director, Technical Operations
+1 978.667.5115 x206
karl.best@oasis-open.org  http://www.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC