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

Title: [humanmarkup] RE: First Working Draft of HM.Requiremen
To Karl and the HumanMarkup TC lists:

This the specific modification I made to our requirements document in regard to these issues:

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.

For TC process requirements refer to http://www.oasis-open.org/committees/process.shtml

For IPR policy refer to http://www.oasis-open.org/committees/

The OASIS HumanMarkup Technical Committee reserves the right to require further restrictions upon the use of its recommended specifications for the purpose of proprietary licensing of applications including said specifications if said use in any way constrains further use of Human Markup Language Specifications. Specifically, we wish to make it clear that an application which uses a Human Markup Language Specification for any application with a modification that renders that or any unmodified Human Markup Language specification obsolete or unusable in whole or in part SHOULD NOT be allowed.

I made this modification  to our requirements document because it occured to me that there is one way in which our work could be nullified, and please excuse me if I have to mention specific practices which currently do this without meaning to explicitly suggest that the same company might use the same practice with regard to any Human Markup Specification.

Using mp3 in Microsoft's Media Player, because of the way that Microsoft's Media Player works, doesn't play standard mp3 files unless they are modified to suit that application. This, in effect, cuts out rival media player software unless a user is willing to make some kind of extra effort because Media Player is integrated into the Windows OS, and in some sense it becomes easier to adopt the Microsoft set of file formats rather than the standard to enjoy this facility using Microsoft's Windows OS. Therefore, I wrote an candidate provision to prevent use of our specification with simultaneous nullification of any other application of it.

We have seen these tactics work before. I think it only prudent to attempt to prevent such practices while we can.

I welcome any comments and I will be writing to the Human Markup lists separately to post the entire new version of the working draft document. I will copy that to Karl as well, but I thought that this was significant enough and possibly controversial enough, that we should deal with it separately from the entire document, which will otherwise contain only minor corrections such as have been discussed on the lists.

It looks like all the time I have spent on IPR task forces comes in handy after all.


At 9:52 AM -0500 3/25/02, Karl F. Best wrote:

> 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

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