Re: [chairs] latest draft of doc mgmt system requirements

[Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>]

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:Eduardo.Gutentag@Sun.COM]
>     *Sent:* Tue 02-Mar-04 11:06
>     *To:* karl.best@oasis-open.org
>     *Cc:* Chairs OASIS; jeff.lomas@oasis-open.org
>     *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:
>     eduardo.gutentag@Sun.COM
>     Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
>     Sun Microsystems Inc.          |         W3C AC Rep / OASIS BoD
> 

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |         W3C AC Rep / OASIS BoD