[rights-requirements] Process clarification requested

[Robin Cover <robin@isogen.com>]

This post is tangential to the SBL's document "Response to
Requirements Analysis September 3, 2002" [1] and also to the
"Feedback requested on Requirements" from Renato Iannella [2]
on the dispositioning of ODRL requirements.  This note
frames its concerns in a slightly broader context.

1.  Process question
------------------------------------------------------------

Hari and Bob: May we please have a joint statement from the
two of you (RLTC REQ SC co-chairs) clarifying the guidelines
(written, unwritten, or both) applicable to the "dispositioning"
of requirements statements as received from external sources?

I have a specific concern about the (non) dispositioning of
declarations in the SBL-2 requirement, and similarly for ODRL-3:

(1) the ODRL Requirements document articulated
    a critical requirement (section 3):

    "that the Rights Language be specified and
    implementable without any encumbrances from patent
    claims. That is, the Rights Language be
    available to all under 'Royalty Free' terms without
    any other conditions."

It was summarized in table 4 thus:

    "The Rights Language must be available under
    royalty free terms."
   
(2) the SBL document, section 2. 'Expressing Rights':

    Any rights language should be able to express in a simple
    and straightforward way any rights in an intellectual
    property in standard XML syntax, such that any user with
    access to a text editor on any platform can avail themselves
    of the language. Such a rights language should be free of
    any restrictions on its use by any user by virtue of
    licensing, patent or copyright restrictions.

(3) similarly, IEEE/IPC statement

    "Any mandated copy protection system and its
    specifications must be available to those implementing
    the system without the payment of a royalty and must
    not impose unreasonable burdens"

While the IEEE/IPC statement (3) has not yet been "dispositioned,"
it appears to me that the ODRL and SBL statements on RL licensing
(1) and (2) above, were summarily dismissed (i.e., disposed of),
as these statements are not reflected in the analysis [2002-08-27]
by any means, not even a characterization as "no transposition
possible" nor by any other signifier.

URLs:
http://lists.oasis-open.org/archives/rights-requirements/200208/xls00007.xls
http://lists.oasis-open.org/archives/rights-requirements/200208/bin00015.bin
referenced from:
http://lists.oasis-open.org/archives/rights-requirements/200208/msg00061.html

or
http://xml.coverpages.org/Collected-Analysis0828.xls

I have been operating under the assumption that requirements
statements from external sources, first of all, would be
factually *recorded* in the analysis without respect to private
(pre-)judgment about feasibility and suitability to the
OASIS TC endeavor.  If the review process has established a
guideline of this kind:

  "The reviewer will examine requirements documents for
  suitable requirements statements, recording those judged
  suitable in an analysis spreadsheet, passing over (without
  comment) any statements not judged suitable for SC discussion."

then I would understand the exclusion of (1) and (2) above as
a reflection of the reviewer's judgment.  Absent any such
process guideline (which I would strongly protest as unfitting
to democratic principles), I would expect that the reviewer's
task is to represent each requirement fairly and accurately,
not to silently dismiss certain requirements thought to be
unsuitable.

Summary of above: My assertion is NOT that the requirements
statements in (1) and (2) above should automatically be
accepted as requirements binding upon the SC/TC.  My point is
that it's procedurally improper to reject (ignore, pass over
without comment) these requirements based upon (?) apparently
unpublished principles.  

2. Example dispositioning
------------------------------------------------------------

From the SBL requirement statement #2:

    Any rights language should be able to express in a simple
    and straightforward way any rights in an intellectual
    property in standard XML syntax, such that any user with
    access to a text editor on any platform can avail themselves
    of the language. Such a rights language should be free of
    any restrictions on its use by any user by virtue of
    licensing, patent or copyright restrictions.

A direct parse of SBL-2 should yield something like this:

"RL:

1) should be able to express IP rights in a simple way

2) should be able to express IP in a straightforward way

3) should be expressible in standard XML syntax

4) syntax-level markup expression should be possible using
      a ['plain'] text editor

5) syntax-level markup expression should be possible using
      any computing platform

6) usage should be free of any licensing restrictions

7) usage should be free of any patent restrictions

8) usage should be free of any copyright restrictions"

These are the requirements as parsed directly from the prose
text.

In a second stage of analysis, it might be necessary to
seek clarification as to what is meant by (e.g.,) "simple"
in 1) and by "straightforward" in 2) so as to analyze these
requirements further, and to reword them (if necessary/possible)
as propositions that can be discussed in terms of machine
language engineering and applicable data dictionary semantics.

What actually happened in the treatment of requirement SBL-2?
The *actual* dispositioning of SBL-2 in the August 27th
spreadsheet asserts that the eight (8) requirements statements
above are handled by a single mapping to:

  R07 == SX03, "Language Definition: The language must be
  defined using XML Schema and all defined names must reside
  in a namespace."

Such a dispositioning obviously ignores #6-8, and does not
necessarily meet the needs envisioned in #1-2 and #4-5.  It
only imprecisely matches #3 since neither [W3C] XML Schema nor
Namespaces are canonically part of "standard XML syntax."

Summary of above: I do not recognize the August 27th
"dispositioning" of SBL-2 as a fair and adequate treatment.
I am made to wonder what other requirements statements have
been summarily and silently dismissed on similar principles.


3. Hint from Thomas DeMartini
------------------------------------------------------------

Thomas wrote in a posting of 22-Aug-2002:

   "The work we have not gotten to yet is the work in the
   specification committee whereby we evaluate the technical
   details of the requirements through CRs.  Which ones are
   fully met?  Which ones are not met at all?  Which ones
   are somewhat-met but could be met better?  What is the
   impact of not meeting it?  Is there a feasible work-around?
   What is the probability that it can be added in an
   amendment (new functionality) without breaking backward
   compatibility?  What is the cost of meeting it?  etc.
   Suppose at some point in time we take all the requirements
   we have at that point in time and break them into three
   sets w, x, y, and z.  W being all the ones that are
   satisfied now.  X being the ones that can feasibly be
   satisfied.  Y being the ones that we don't have any
   solutions for at the moment (because of our own limited
   expertise) but that we have a good feeling for could be
   added in a backward compatible ammendment at some future
   point when the demand for such requirement grows and the
   expertise is available to meet it.  Z being the ones
   that are technologically not possible for a long time..."

This posture supplies (what I would suggest as) an analog for a
fair "dispositioning" of the requirements statements: they all
need to be recognized as legitimate, since they originate
with real application domains and real "clients."  Every such
requirement statement merits formal acknowledgement in an
atomic utterance/proposition. Not all such propositions can be
accommodated (as-is) into the consensus Requirements Document.
In the framework of subsequent TC discussion and deliberation,
many such reqirements will need to be clarified as to intent
(what is meant, what is not meant); some such requirements
may require modified phraseology in order to be useful; some
may present tension with other reqirements, and (through
negotiation, compromise) may need to be substantively modified
in order to be feasible; some of them may need to be delayed,
some of them ultimately may need to be rejected as inappropriate,
etc.

Note: this approach however does *not* allow for any requirements
statements to be ignored and thus dismissed out of hand, on
apriori grounds, without discussion.

4.  Motivations given
------------------------------------------------------------

The IEEE/IPC statement (3) appears to supply no motivating
explanation, but the SBL-2 and ODRL-3 statements are very
clear: these are business model (business case)
requirements.

Justification for the ODRL-3 requirement was grounded in a
statement quoted from the TC Charter:

   "The ODRL Initiative notes that Charter of the
   OASIS Rights Language TC includes: '...a rights
   language that supports a wide variety of
   business models ... flexibility to address the
   needs of the diverse communities that have recognized
   the need for a rights language...'  This implies a
   requirement for the Rights Language to be made
   widely available without any impediments to such
   groups (e.g., the open-source community, cultural
   institutions, individuals, etc.) in the true
   interests of interoperability."

Justification for the SBL-2 requirement was articulated
thus:

   "Reasoning: Academic users are currently protected by
   copyright laws of various jurisdictions without use
   of proprietary software or payment of fees for the
   occurrence of those protections. While vendors may
   offer software with enhanced ease of use features for
   any rights language, it should not be the case that
   a rights language should be restricted users who can
   pay to protect their own rights. It is the intent of
   this requirement to duplicate the protection of
   copyright, which does not require licensing of copyright
   to protect one’s own intellectual property."

Some earlier postings on the TC list declared that discussion
about licensing was "off topic" because the TC is a technical
and not a legal forum. I declare that argument utterly specious:
when a requirement springs directly from a business model,
it constitutes a first order requirement, however it might
touch upon or imply assessment of (possibly relevant) legal
realities as downstream input to technical considerations.
It is totally specious to declare: "*Our* business model
[backed by elaborate protectionistic legal claims favorable
to our company, supported and instantiated already in a
developed specification] is untouchable; your business model
cannot be discussed because it touches upon legal matters."

Standards are not created in a vacuum named "Open Lab for
Technological Achievement."  Standards are created within a
global social framework involving norms, laws, business
models, timeframes, adoption scenarios, economic concerns,
and many social factors, together with consideration for
technological feasibility and technical excellence.

Obviously there's a lot to talk about here. There is also a
lot to talk about in response to the SBL document of
September 3, 2002, in response to Iannella's ODRL feedback,
and in response to the related IEEE requirement(s). That's
precisely my point. The SBL-2, ODRL-3, and IEEE requirements
demand formal recognition and discussion, however much
debate they might engender and compromise they could imply;
they do not deserve to be dismissed without comment.

Robin

--------- Notes:

[1] SBL Response.  See:
http://xml.coverpages.org/SBL-DRM-Response.pdf   with source in:
http://lists.oasis-open.org/archives/rights-requirements/200209/msg00004.html
http://lists.oasis-open.org/archives/rights-requirements/200209/bin00000.bin

[2] ODRL Response

The message from Renato Iannella <renato@iprsystems.com>
was posted to the OASIS list
'rights-requirements@lists.oasis-open.org' but the message
was bounced by the mail server, as Renato was not recognized
as a list member; the message was copied to Hari Reddy, Hal
Lockhart, and RCover, arrived Tue, 3 Sep 2002 21:01:07 -0500
(CDT).  Here is the essential text:

[Renato Iannella writes]

============================================================

Hari, thanks for the review of the requirements
from the ODRL Initiative. However, there was one
requirement "Royalty-Free" (Section 3, Table 4)
that was not in the final analysis. I also noted
that the same issue appears in the requirements
submitted by two other organisations (Society of Biblical
Literature, and the IEEE). It would be useful to include
this requirement in the final analysis.

Also, the requirements seemed to have been analysed against
a known set of criteria for a Rights language.
Normally, requirements are gathered and analysed
to create/establish the criteria.

I will not be able to make the teleconference as it is
scheduled for early AM Australian time.

============================================================

Robin Cover
XML Cover Pages
WWW: http://xml.coverpages.org
Newsletter: http://xml.coverpages.org/newsletter.html