I think most people must be seeing red by now ;-)
Laurent, could you clarify something? Seems to me that there is a
difference between red rows where there is a possible workaround
and red rows where there appear to be no possible workaround (see
rows 27 and 28 for respective examples of this); wouldn't it make
sense to use different colors to make this more obvious? For
instance, I think that there is a big difference between not being
able to display committees by category or by name, on the one
hand, which would be bad enough, and not being able to keep a
count of whether a member has reached participation obligation or
not, which would be, I think, quite worse. Is the lack of
differentiation an indication that although there is no current
workaround known there may be one in the future? Or is this an
indication that no prioritization (if that is the right word) has
been done on this yet?
Another question: How would this affect the work of Drupalization
that Carol and Jose have been doing over the past few years. Out
the window?
And finally: some of the non-red rows have potential workarounds,
but there is no indication of the extent of work that would have
to be invested on each of them and whether it would be a one time
effort or a continuing maintenance issue. Are you planning on
making that kind of determination soon?
Thanks!
On 07/21/2010 09:50 AM, Laurent M Liscia wrote:
[Resending
to the broader Agenda list]
Preamble: We are considering migrating our data to Kavi 5; and
have produced the attached spreadsheet to highlight the difference
between what we have currently on our custom OASIS version of
Kavi, maintained by us, and what is available on Kavi 5.
Executive Summary (to help navigate the spreadsheet)
To adequately assess the impact of migration to a Kavi-hosted
solution it is necessary to distinguish between two classes of
OASIS applications.
1. Kavi apps
Kavi apps support TC "workspace" activities and membership
functions. In the current system this corresponds to things under
www.oasis-open.org/apps/... and www.oasis-open.org/members/...
2. OASIS apps
OASIS apps are, essentially, everything else related to
www.oasis-open.org. Internally these are often referred to as
"www" ("dub-dub-dub") apps. For example (non-exhaustive):
http://www.oasis-open.org/home/index.php
http://www.oasis-open.org/who/
http://www.oasis-open.org/join/
http://www.oasis-open.org/specs/ (approved standards)
http://tools.oasis-open.org/ (Wikis, SubVersion repositories)
Member Sections, e.g. http://www.oasis-blue.org/
Public email archives (http://lists.oasis-open.org/archives/)
Currently, both classes of application are hosted in-house by
OASIS and are driven by a common, local data backend (MySQL
database, email directories) and therefore tightly coupled.
Kavi corp will host only Kavi TC workspace apps. This means that
OASIS must continue to host (or contract with someone other than
Kavi corp to host) the www.oasis-open.org domain (and associated
(sub)domains) in order to support OASIS www apps and to map URIs
such that the existing self-hosted Kavi app URIs continue to
resolve correctly post-migration.
Backend data required to support Kavi apps is owned by Kavi and is
not accessible to external non-Kavi applications. Should the
OASIS Kavi apps migrate to a Kavi corp hosted solution, the
database goes with them and is no longer available to OASIS www
apps that need it. This requires that OASIS www apps be
decoupled from the Kavi app database.
A detailed list of the deltas resulting from a Kavi 5 migration
in spreadsheet form is attached (note that spreadsheet line items
highlighted in red indicate deltas that arise specifically when
OASIS www apps no longer have access to data in the kavi 5
database). A summary of the deltas is provided immediately below.
OASIS www content
Various content served up by the OASIS www apps is generated
dynamically using data queried from the Kavi database. Should the
Kavi apps migrate to a Kavi hosted solution, that data would no
longer be available. This dynamically generated content would
either have to be converted to manually maintained static web
pages or the database would need to be manually mirrored and
maintained by OASIS staff.
Affected content includes but is not limited to:
Public TC home pages e.g. OASIS look and feel, list committees
by category, IPR pages, obligation counter …
Member sections: membership lists, member section Committee lists
Membership-based Access Control
Not all features of OASIS www apps are available to the general
public. For instance, certain operations on TC Wikis and
Subversion repositories are available only to TC members acting
in certain roles. The OASIS tools applications implement this
level of access control "seamlessly" today by reading TC
membership and role data in the shared backend database.
Should the Kavi apps migrate to a Kavi hosted solution, the data
regarding TC membership and roles goes with it and would no
longer be available to OASIS tools. Maintaining the appearance
of seamlessness would require OASIS staff to manually mirror and
maintain TC membership and role data in the Kavi database and make
it accessible to the OASIS tools applications.
As of this writing 52 TC Wikis and 18 TC SVN repositories would
be affected by this.
The ability to restrict access to certain email archives (e.g.
Board of Directors) is similarly affected.
Access control for the OASIS STV ballot application is affected
as well.
Public Email Archives
From http://lists.oasis-open.org/archives/:
"OASIS hosts a wide variety of mailing lists to enable
collaborative work among members, facilitate public input, and
communicate with the global community. In support of its
commitment to information access as a foundational principle in
open standards development, OASIS provides archives for all
mailing lists, the majority of which are viewable by the public.
The OASIS mailing list archives may be searched using either
MarkMail or Google."
OASIS mailing list apps and the Kavi email functions are driven
from a common email data repository. Should the Kavi apps migrate
to a Kavi hosted solution, that repository would no longer be
available to the OASIS mailing list apps.
---------------------------------------------------------------------
This list is for posting purposes only. Any discussion of agenda items
should be held on the board-comment@lists.oasis-open.org list. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: board-agenda-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: board-agenda-help@lists.oasis-open.org
--
Eduardo Gutentag | Director, Standards Strategy
& Policy
Phone: +1 510 550 4616
| Fax: +1 510 550 4616
| SMS: +1 510 681 6540
Oracle Corporate Architecture Group
5op334, 500 Oracle Parkway, | Redwood Shores, California 94065
Oracle is committed to developing practices and
products that help protect the environment
|