[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: recent OASIS Document Management (not-Kavi) requirements
Hi, A couple of weeks ago I forwarded some more recent OASIS document management proposals from members of the team working on the OASIS document management requirements. Over the past week or so there have been about a dozen additional suggestions sent. I've collated them here so that you can quickly look them over and let me know if you have any strong opinions on any of them, pro or con. The next OASIS document management meeting is this coming Monday at 1:00 PT. If have any input on any of these suggestions, please send it to me before noon on Monday. The alias for these discussions is doc-mgmt@lists.oasis-open.org. The list is moderated. You can join the alias to monitor the discussions if you're interested. I'll also forward relevant info as appropriate. Thanks, -Anne
From: Rex Brooks <rexb@starbourne.com> I realize it is a bit late to be adding anything to the issues list/wish list at this point, so I only wanted to review my request in the last call. There is a wealth of supporting materials developed during research, links, and explanatory materials that go into these specs, and it would be helpful if we had either: a) a separate page such as we have for Documents, Minut4es, etc ( to which we could have ftp access and which we could structure for ease of understanding by the public) for those materials to be accessible by the public from the TC webpage; or, b) a more legible assortment of categories in the documents sections of the kavi setup. I find the boxed-in tables of lists distracting, and the lack of space for explanations to which the public has to link in order to see more boxed in details to understand what they are requesting. I don't mind it for the TC documents per se, but for public it is quite a bit of effort to get documents one at a time, and there simply is no way to offer a set of links to reference sites. Ciao, Rex ------------------------------------------------------------------------ From: Patrick Durusau <pdurusau@emory.edu> I don't know that all TC members would want it but it would be nice to have the option to have documents emailed to requesting members when they are placed in the document archive. I try to remember to get the most recent files when I am traveling but invariably I am in an airport and I am missing the most recent version of a document. Not sure it falls under document management but having the ability to request tar/zipped archives from the mailing lists would also be quite handy. ------------------------------------------------------------------------ From: David RR Webber - XML ebusiness <Gnosis_@compuserve.com> Karl, I would recommend bringing up your own WIKI server. Right now I'm supplementing the Kavi with the cam.swiki.net - its incredibly easy to setup - very versatile - and I think would give those people that want more flexiblity - the right answer. You could host : owiki.net DW. From: "Karl F. Best" <karl.best@oasis-open.org> This first phase was supposed to be for gathering requirements (not suggested solutions) but we can add this to the list for later. -Karl From: David RR Webber - XML ebusiness <Gnosis_@compuserve.com> Ooops! You got me ; -) I'd seen all these needs from people earlier as we migrated to Kavi, who want to have chunks of schemas and html in sub-directories and sub-sub-directories with embedded links - so I was thinking - give them a sandbox they can configure to their hearts content - and does all the tracking and history automatically. Also - I like the way you can do guest books, FAQs and Comment areas in WIKI automatically, and quickly add download and resource sharing areas.. This is a very nice ad hoc collaborative toolset that compliments Kavi well. And maybe that is simply put what the need is here. Kavi = formal collaboration, WIKI = ad hoc collaboration + tracking. Cheers, DW. ------------------------------------------------------------------------ From: Rich Thompson <richt2@us.ibm.com> A requirement that I notice is missing is for a stable URL to point to the latest revision of a document. This will often be useful on public pages and press releases. Rich Thompson ------------------------------------------------------------------------ From: "Matthew MacKenzie" <matt@yellowdragonsoft.com> Sorry if this requirement includes a proposed solution, that is a habit of mine :-) REQUIREMENT I would like to see a simple tool that integrates to kavi and provides a way of formally assigning a URN to a document, and using a uniform URL structure provides access to the document at its actual, Kavi-managed location. SOLUTION So, given that the ebxml-msg SOAP extension schema is actually located at http://www.oasis-open.org/kavi/somephpscript.php?did=3e77jjdjjd, the new script would provides a URL like: http://names.oasis-open.org/ebxml-msg/schema/2_0 and transparently forward to the actual location. TC chairs and secretaries would be able to setup forwarding for any publicly published document. This could be easily implemented using a PHP script and one database table. I beleive this would solve some other problems as well. -Matt ------------------------------------------------------------------------ From: "Drummond Reed" <drummond.reed@onename.com> To: <doc-mgmt@lists.oasis-open.org> Cc: "Gabe Wachob (E-mail)" <gwachob@visa.com>, "Marc Le Maitre (E-mail)" <marc.lemaitre@onename.com> Subject: RE: [doc-mgmt] formal & explicit urn/url assignment X-MIME-Autoconverted: from quoted-printable to 8bit by jurassic.eng.sun.com id h4K5EUsX516109 RE the subject of formal & explicit URN/URL assignment, the XRI TC is tackling requirements for abstract identifiers of all kinds - essentially a superset of the requirements for URNs. The all-but-final requirements doc is at: http://www.oasis-open.org/apps/org/workgroup/xri/download.php/2050/xri-r equirements-1.0-draft-05b.doc <http://www.oasis-open.org/apps/org/workgroup/xri/download.php/2050/xri- requirements-1.0-draft-05b.doc> A quick list of those I would highlight relative to OASIS doc-mgmt: 1) The ability to create human-friendly identifiers that map to persistent OASIS URNs or to current document locations (pretty much what Matthew advocates below). 2) The ability to standardize cross-references within documents (standardized fragment identifiers). 3) The ability to standardize version syntax. =Drummond ------------------------------------------------------------------------ From: "Karl F. Best" <karl.best@oasis-open.org> Here's a few more things that I thought of over the weekend. security -------- - owner/submitter recorded as part of submission - owner/submittter has rights to modify (make new version), but not replace or delete (this is a permanent repository) - TC chair, sec, editor has ?what? rights in directory URL --- - file has persistent identifier/URL regardless where the file (or package) is actually stored. - mechanism for resolving URNs embedded in schemas, etc. - URL is compact; not full of database query string/characters versioning/metadata ------------------ - uses OASIS file naming scheme (developed on TC chairs list; inlcudes draft, CS, OS, etc.); does the TC editor assign names, or can the doc mgmt system do this? Perhaps a checkbox at submission to specify name and stage, etc. then doc mgmt system checks for uniqueness, versioning, etc. The TC Admin owns all OS-level docs and assigns those names - metadata includes filename, submitter/owner, TC, date created/modified, IPR, etc. legacy ------ - resolve current document addresses/URLs - import existing docs from ftp and from Kavi; persistent names files ------ - Multi-part files: a single spec can be composed of a number of files; submitter can upload entire package, and can also upload/modify just one of the files; user can download entire package. - Doc can be any file type; package may contain any combination of file types interface/process ---------- - TC mail list notified when file/package submitted or modified; notification includes metadata and link to download. - Entry added to TC web page with new/modified file (page on TC's web area is the entry point for all TC's docs.) - web form (from any browser) is interface for submission/modification; use Kavi account/pswd for authentication? - doc mgmt area created for new TC when TC created in Kavi; chair/editor permissions inherited from Kavi ------------------------------------------------------------------------ From: Jeffrey Lomas <jeff.lomas@oasis-open.org> It has come up recently that the posting of TC minutes are not being done consistently in a way that makes them available to the public. Jeff ------------------------------------------------------------------------ From: Kelvin Lawrence <klawrenc@us.ibm.com> Subject: Re: [doc-mgmt] requirement: Consistent posting and maintenance of public TC meeting minutes Jeff, I would expand this to say that the new Kavi based system has changed OASIS documents from being fully public to being a mix of public/semi-public (OASIS members only) and private (TC members only). So while I agree with your finding - I would assert that it is far more pervasive a problem than just TC meeting minutes and that it in fact includes documents and many other things. Given the defaults are private when creating documents this is perhaps not surprising. Cheers Kelvin ------------------------------------------------------------------------ From: Winters, Roger [mailto:Roger.Winters@METROKC.GOV] Dear Mr. Best: I want to offer a few suggestions about requirements for document management for OASIS committees. Be advised that, though I am in a secretarial role for the Legal XML Electronic Court Filing Technical Committee, I am not yet fully conversant with those duties and powers. It is as Editor for the TC that I offer these thoughts. I hope you'll forgive me if some of these suggestions ask you, due to my ignorance, to do things that you have already handled within OASIS. 1. Naming Although OASIS has adopted well-developed naming conventions for documents proceeding through its processes, there are a number of instances where a working group needs to share and process files of various kinds, many of which would not themselves become drafts of committee specifications. It would be helpful if, regardless of the filenames given to documents, there were a way to enter a descriptive title that would be shown on the appropriate Web page, to serve as a clickable link to the file. This seems advisable because few of the members are likely to learn the naming conventions because, even though they have a rational and well-defined basis, they look complicated. Once a file gets to a certain point in the OASIS process, e.g., when it becomes appropriate for the Editor to take charge of it as a draft committee specification, the formalities of the naming conventions should be followed carefully. Even then, assigned easy-to-understand titles would be preferable to tit! les that reflect either the filename or the first few words in the document. 2. Document Version Management This is, of course, a basic requirement for document management systems, along with having check-in/check-out read/write privileges and controls. It is also helpful to provide guidance, perhaps in a "Document Management Help Page," on what might warrant preserving a current version and issuing a new number to its changed version. I think such version control is likely to be a useful and important tool even at the subcommittee level; that is where participants are more likely to need guidance in finding a balance between meaningful versioning and needless proliferation of files. Tools to manage document ownership and check-in/check-out functionality need to be easy to understand and not too difficult to implement. For example, a term limited subcommittee chair might need only a few simple tools that can be quickly and easily mastered. 3. Document Disposition Although I am involved with records management, I am not an expert. This is an area where OASIS might want to engage records and information management experts to help design records retention and disposition policies, procedures, and tools. It is important to resist the temptation to "save everything because storage is cheap," because there are other issues and costs besides storage involved in records management. A records retention schedule is advisable, with a disposition strategy that ensures that records scheduled to be disposed of are in fact eliminated. I'm glad to participate in future discussion of these matters. Regards, Roger Roger Winters Electronic Court Records Manager King County Department of Judicial Administration 516 Third Avenue, E-609 MS: KCC-JA-0609 Seattle, Washington 98104 V: (206) 296-7838 F: (206) 296-0906 roger.winters@metrokc.gov ------------------------------------------------------------------------ From: jkeane <jik@jkeane.com> Here is a chart we used in a discussion about organizing the burgeoning LegalXML document collection. This may help people visualize different uses and perspectives for document management and retrieval. The Kavi repository only addresses some of the functionality depicted. The LegalXML folks did not get to the point where we approved this or any other approach to the structure of a document repository. The diagram depicts a Bibliographic database with links to a searchable collection of full text documents. Like a Content Management Systems it should re-use the same objects in many different publishing and research displays and reports. We were in general consensus that we should use an XML bibliographic schema for the core document record. In Bibliographic Retrieval systems and web based systems like Cold Fusion there is an underlying database that dynamically publishes html (or XML) displays and reports (author index, subject index, index to different standards, etc. ) from database records. The only changes are to the database. We should not have to create static html in different pages and then manually synchronize citations, URI's and other retrieval data elements. We should also make sure any software we consider allows true full text searching not just of data elements but also of the underlying full text of documents in native format, PDF or rtf. Unformatted full text is not the optimum storage media. We should also look beyond Boolean operators and proximity searching to Concept searching, Natural Language Queries (NLQ), "smart" search engine and even knowledge mapping software. We received many inquiries during the LegalXML first years from students, researchers, curious technical people and, yes, lawyers, who were not always in a position to frame knowledgeable searches for "style-sheets' or' BLOBS' or from technical folks who might not know the difference between Return of Service and a Certificate of Service. I differ with Roger's excellent points on one quantitative dimension of purging and pruning the collection. If the documents represent the history of our thinking and deli liberations, even drafts can be important source documents. We will also have links in the public archives to documents in various stages of consideration. This may necessitate one final element in our list of requirements and that is a link to the final version of official documents. All the best Jim Keane Vice Chair, Legal XML Steering Committee Co-Chair, OdrXML TC JKeane.Law.Pro '<Litigation Systems Analysis>' http://www.jkeane.com 20 Esworthy Terrace North Potomac MD 20878 Phone: 301-948-4062 Fax: 301-948-8924 (N.B.: NEW FAX NUMBER) Co-Author and Annual Update Editor of Litigation Support Systems, An Attorney Guide 2nd Ed. (WestGroup, 1992, 800 pages, looseleaf, updated through 2002) ------------------------------------------------------------------------ From: Jason Harrop <jharrop@speedlegal.com> Here is another requirement for interface/process interface/process: - Client applications which support WebDAV (eg XML Spy, OpenOffice, Microsoft Office 2000/XP, Adobe Framemaker, Adobe Acrobat, Eclipse etc) must be able to get documents from the DMS using WebDAV, edit them, and put them back. ie WebDAV can be used as an interface for submission/modification. ------------------------------------------------------------------------ From: Rex Brooks <rexb@starbourne.com> All, I realize it is a bit late to be adding anything to the issues list/wish list at this point, so I only wanted to review my request in the last call. There is a wealth of supporting materials developed during research, links, and explanatory materials that go into these specs, and it would be helpful if we had either: a) a separate page such as we have for Documents, Minut4es, etc ( to which we could have ftp access and which we could structure for ease of understanding by the public) for those materials to be accessible by the public from the TC webpage; or, b) a more legible assortment of categories in the documents sections of the kavi setup. I find the boxed-in tables of lists distracting, and the lack of space for explanations to which the public has to link in order to see more boxed in details to understand what they are requesting. I don't mind it for the TC documents per se, but for public it is quite a bit of effort to get documents one at a time, and there simply is no way to offer a set of links to reference sites. Ciao, Rex
LXMO Document Layout 1dt 2002.12.10.ppt
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]