I agree with Eduardo that this would not be an IPR issue. Nothing may be
brought to OASIS that rquires confidentiality.
The closed door approach for the first phase was suggested, I believe,
because the work being done in the "sandbox" was very early and raw, and
possibly not something that anyone would want their name attached to. I
can understand that point of view, but I agree with Eduardo that this is
contradictory to the nature of OASIS work which must be done in the
open. I also agree with the concern of work never progressing to the
second pahse; I'd hate to see work never progress and therefore never be
made public.
Does anyone have a suggestion for why it might be important to have the
"sandbox" work not be publicly viewable?
-Karl
Eduardo Gutentag wrote:
>
>
> Rogers, Tony wrote:
>
>> What about those TCs which are working on material that has IPR issues
>> attached?
>
>
> To the point that no one other than TC members can look at that
> material? I'm not
> aware of any such circumstance. Nor do I know if it would be even possible
> for that to happen, given that the moment one brings a contribution into
> OASIS the following applies: "No contribution that is subject to any
> requirement of
> confidentiality or any restriction on its dissemination may be
> considered in any
> part of the OASIS Standards Process, and there must be no assumption of any
> confidentiality obligation with respect to any such contribution. No
> submission
> should be made on the basis of an assumed confidentiality obligation or
> restriction
> on dissolution." (OASIS.IPR.2 Confidentiality Obligations, to be found in
> http://www.oasis-open.org/who/intellectualproperty.php)
>
>
>
>
>>
>> -----Original Message-----
>> *From:* Eduardo Gutentag [mailto:]
>> *Sent:* Tue 02-Mar-04 11:06
>> *To:*
>> *Cc:* Chairs OASIS;
>> *Subject:* Re: [chairs] latest draft of doc mgmt system requirements
>>
>> All,
>>
>> I just noticed this:
>>
>> > First Phase
>> > --------------
>> [...]
>> >
>> > * Documents viewable only to TC members. Access control based
>> on Kavi
>> > database; only TC members (and SysAdmin) may access this area
>> >
>>
>> Where is the motivation for such a statement coming from? This kind of
>> TC secrecy totally contradicts the open spirit of OASIS. Why do we
>> need
>> this? Why not work in the open? What are we trying to hide? What
>> are TCs
>> trying to hide? How are TCs going to get input from others if the
>> others
>> can't see what the TCs are doing? What if a TC does not get to phase
>> 2 ever?
>> Will its Phase 1 documents be forever closed to study?
>>
>> I think this would be a disservice to OASIS members, and should not
>> be carried
>> out. One of the things that has distinguished OASIS from other
>> organizations
>> over the years has been its openness and lack of secrecy. This
>> distinction is
>> on the verge of disappearance, and this would be just one more nail
>> in its
>> coffin.
>>
>> The argument that people are stupid (generally expressed as "we
>> don't want to
>> confuse people who are not in the TC, who would perhaps think that
>> something
>> is finished or complete when it is just random thoughts") is
>> unworthy of us.
>>
>> Thanks.
>>
>> Karl F. Best wrote:
>> > Chairs:
>> >
>> > Attached is the latest draft of the doc mgmt system requirements,
>> which
>> > I hope adequately takes into account the many fine comments and
>> > suggestions that you provided last week. Further comment always
>> welcome.
>> > Jeff and I will start work on creating a system design based on
>> these
>> > requirements.
>> >
>> > (Provided in text format as suggested by Norm :-)
>> >
>> > -Karl
>> >
>> >
>> >
>> > OASIS DocMgmt Functional Requirements
>> > (25 February 2004)
>> >
>> > First Phase
>> > --------------
>> > * General description: A simple, open collaborative document
>> development
>> > environment (sandbox) for members of TCs and SCs to jointly develop
>> > specifications and other documents in a free-form environment.
>> > - Probably Wiki? (Twiki? MoinMoin?)
>> > - Separate area for each TC and SC
>> >
>> > * Documents viewable only to TC members. Access control based
>> on Kavi
>> > database; only TC members (and SysAdmin) may access this area
>> >
>> > * Ability to merge changes from multiple people into a single doc
>> >
>> > Transition
>> > --------------
>> > * OASIS will need to provide guidelines/criteria for when docs
>> may or
>> > must advance to the next phase (the controlled repository)
>> >
>> > Second Phase
>> > --------------
>> > * General Description: A controlled document management/versioning
>> > environment; a repository providing storage/management of files
>> created
>> > by TCs, SCs, and other OASIS groups
>> > - Probably based on CVS with customized interface (WebCVS?
>> WebDAV?
>> > Subversion? TortoiseCVS?)
>> > - All documents are permanently archived (only Admin has
>> delete rights)
>> > - All documents are publicly viewable, downloadable
>> >
>> > * Data structure
>> > - A separate area in the repository for each TC/SC/group
>> > - Both default and definable hierarchy within each TC area;
>> default
>> > folders for “drafts”, “minutes”, “press”, “contributions”, etc.
>> (TBD) TC
>> > chair/editor has ability to create additional folders (Restricted
>> to NN
>> > levels?)
>> > - Document metadata (filename, title, date, description,
>> creator,
>> > language, associated files, etc.) stored in XML(?) (Depending on
>> > capabilities of engine e.g. CVS). Metadata schema is TBD and
>> needs to be
>> > editable over time by SysAdmin. Should include at least one
>> free form
>> > field definable by the TC.
>> >
>> > * User interface
>> > - Repository has a web interface for uploading and tree
>> browsing,
>> > searching, and retrieval. Support for all major browsers.
>> Intuitive UI
>> > should require little or no user documentation.
>> > - Repository has command line interface for power users; this
>> > interface will have the same access control and restrictions on
>> > permissible actions, etc. as the web interface.
>> > - Search/retrieval
>> > - Files may be found via search and by tree browsing
>> > - Search by any of the metadata fields
>> > - Full-text search of contents (except for binary formats)
>> > - Listing of single files in browsing and search results
>> includes
>> > the metadata fields. The listing for packages includes the list of
>> > single files in the package, then drill down for information on
>> those
>> > files.
>> >
>> > * Persistent URLs
>> > - At file creation (first checkin) the document is assigned a
>> URL by
>> > the creator. The URL must be predictable in advance of checkin.
>> URL in
>> > the form of e.g.
>> http://docs.oasis-open.org/<tcname>/<dir>/<filename>
>> > where <filename> corresponds to the OASIS file naming scheme
>> including
>> > the version but without the revision number. (The URL would not
>> include
>> > the revision level but the filename would.)
>> > - The assigned URL will always resolve to the latest revision
>> of the
>> > document, regardless of the document’s (revisioned) filename;
>> the URL
>> > will identify a specification throughout its entire lifetime from
>> > working draft to OASIS Standard. (This implies that the person
>> checking
>> > in the file must be able to specify the old file that this new
>> one is
>> > replacing.)
>> > - Previous revisions of the document will be accessible via a
>> variant
>> > of the URL containing the revision number.
>> > - (Version number is for versions of the specification, e.g
>> v1 is
>> > approved as an OASIS Standard after which work on v2 is
>> started. Each
>> > version will go through a number of revisions during its
>> lifetime, e.g.
>> > .01, .02, ... .99. See the OASIS filenaming spec.)
>> >
>> > * Multiple file types supported
>> > - Any type of file may be uploaded (not restricted to e.g.
>> just .doc
>> > or .htm).
>> > - TCs must be able to store both source (e.g. MSWord, XML, or
>> HTML)
>> > and compiled (e.g. PDF) versions of each file. The repository
>> should
>> > have some means to connect two different files (e.g. foo3.htm and
>> > foo3.pdf are different representations of the same file); the
>> user can
>> > upload and associate all formats in a single operation. Search
>> results
>> > should show all available formats of the same file and the user
>> should
>> > be able to select/retrieve one or all.
>> > - HTML files may include graphics which will be stored with
>> the file
>> > (use relative URLs?)
>> > - (CVS functionality will not be the same for binary/proprietary
>> > files as for text-based formats, i.e. it cannot provide the same
>> > functionality for a .doc as for an .xml file. Functionality for
>> diff,
>> > merge, change logs, etc. not available. The TC will have to
>> decide which
>> > format is best for them based on the capabilities they require.)
>> >
>> > * Packages
>> > - A specification may be composed of multiple documents. A
>> “package”
>> > is a collection of related files (e.g. chapters in a book or
>> parts of a
>> > modular schema or DTD). The various parts can be the same or
>> different
>> > file types.
>> > - The package file is an HTML file (similar to a ToC) created
>> by the
>> > TC with links to and metadata for the various components.
>> (OASIS will
>> > need to define a format/syntax/template for this package file.)
>> > - The package is updated by editing the links in the package
>> file.
>> > Each of the components are maintained by editing it individually.
>> Each
>> > component, as well as the package file, has its own revision
>> number, but
>> > the entire set would collectively have a version number.
>> > - The entire “package” may be uploaded or downloaded in a single
>> > operation. Individual documents in the package may also be
>> uploaded or
>> > downloaded.
>> > - Support for chapters or parts of a multi-part document (with
>> links
>> > between parts); a package could have a ToC with links to the
>> individual
>> > files
>> > - Support for modular DTDs (e.g. DocBook)
>> > - The entire “package” is addressable via a single URL
>> pointing to
>> > the package file which in turn links to the individual files in the
>> > package.
>> >
>> > * Security
>> > - Access control: check-in/out based on Kavi user
>> authentication;
>> > different permissions for public, TC members,
>> chair/secretary/editor, etc.
>> > - Public has read rights for all documents
>> > - TC members have read rights
>> > - TC Chair, Secretary, and Editor have create, edit rights for
>> > folders and create and checkin/out rights for documents in their
>> > respective TC area
>> > - Admin has admin rights (create, checkin/out, modify, delete
>> of all
>> > folders and files)
>> >
>> > * Kavi integration
>> > - Kavi user acct/pswd used for authentication
>> > - Notification to the Kavi group when a document is uploaded
>> (similar
>> > to current Kavi notification)
>> > - Links to the interface of the current Kavi doc repository are
>> > redirected to the new doc mgmt system (i.e. interface to the
>> Kavi doc
>> > repository is no longer the default, this one “drops in” to
>> replace it).
>> > - Docs currently in the Kavi repository will continue to be
>> > addressable and viewable by their Kavi URL. The Kavi listing and
>> > searching functions may still be accessed by users, but won’t
>> be the
>> > default. (Current docs in the Kavi repository are allowed to stay
>> where
>> > they're at until the TC wants to move them.)
>> >
>> > * Localizable interface, with localization to occur in a later
>> phase
>> >
>> > Later phase functionality
>> > ---------------------------
>> > * File naming automation: Naming and versioning of documents
>> follows
>> > OASIS file naming scheme; when a new document is created
>> automated helps
>> > (pulldowns for each of the segments of the filename) will appear
>> to help
>> > the user to create/assign a conformant name and retain uniqueness.
>> >
>> > * Localized interface (priority for which languages TBD)
>> >
>> > * Count/traffic report of downloads (e.g. how many people have
>> > downloaded a particular doc?)
>> >
>> > * File validation (schema parsing) upon checkin
>> >
>> > * Publishing (convert to PDF or HTML) upon checkin
>> >
>> >
>> >
>>
>> --
>> Eduardo Gutentag | e-mail:
>>
>> Web Technologies and Standards | Phone: +1 510 550 4616
>> x31442
>> Sun Microsystems Inc. | W3C AC Rep / OASIS BoD
>>
>
--
=================================================================
Karl F. Best
Vice President, OASIS
office +1 978.667.5115 x206 mobile +1 978.761.1648
http://www.oasis-open.org
