OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook-tc] Draft Kavi message


Hi Norm,

I wholeheartedly agree, and approve "signing" my name to this document.

Best regards,

--Scott

Norman Walsh wrote:

>At the last meeting, I took an action to draft our committee response
>to OASIS about the state of Kavi. Here it is. (Bob, please make sure
>we have an item on the agenda for discussing this.)
>
>The DocBook Technical Committee would like to express its continued
>frustration with the document management part of the Kavi system
>implemented at OASIS. We find the system to be technically inadequate
>at best and flatly broken at worst. Beyond the technical issues, we
>are concerned that it is an awkward, difficult to use system and
>consequently we fear that it may be driving users away from OASIS.
>This is not only bad for our committee, it is bad for the consortium
>as a whole.
>
>It is our unanimous opinion that the Kavi system as currently
>implemented has critical flaws, and that it is imperative that they be
>corrected. We are aware that some of these issues have been brought to
>your attention before by individuals, but we would like to reiterate
>them here as part of our committee position.
>
>We draw your attention to the following technical issues.
>
>1. The document repository is simply broken. Although chairs and
>   secretaries can organize documents into a hierarchy, this hierarchy
>   is not exposed to the general public. This frustrates any attempt
>   that the committee might make to organize the documents for the
>   public.
>
>2. The Kavi system forces documents to have automatically generated
>   URIs that are meaningless and difficult to remember. Even if we
>   were able to accept the URIs generated, it is impossible to predict
>   the URI that will be assigned to a document when it is placed in
>   the repository. This makes it impossible for the committee to
>   decide offline, for example at a face-to-face meeting, where and
>   how documents will be published.
>
>3. Another consequence of the fact that URIs are generated by the
>   system rather than assigned by the committee with responsibility
>   for the material is that it is impossible to publish specifications
>   that contain internal cross references. An HTML version of a
>   specification, for example, cannot contain a link to the PDF
>   version.
>
>4. This also makes it impossible to publish a web of documents. A
>   large document could not be broken into chapters, for example, with
>   navigational links between the chapters.
>
>5. It follows further that the DocBook Committee *cannot* publish the
>   DocBook DTD on the OASIS site. DocBook is a modular DTD and the
>   URIs of the modules must be predictable. In fact, as a general
>   rule, it would seem that no Technical Committee can publish any
>   schema, stylesheet, or other work product of any reasonable
>   complexity on the OASIS site other than as a zip package or
>   something similar for the user to download and install locally.
>
>6. The OASIS email system is unable to deal with properly formatted
>   MIME messages. It simply discards their contents and forwards a blank
>   message to the list. This is causing considerable frustration and wasted
>   effort. We observe also that several individuals have approached the
>   committee to express frustration with the mailing list software.
>   This situation is inhibiting communications within OASIS TCs thereby
>   slowing down work by its members.
>
>7. The design of the OASIS web server is insufficient for the needs of
>   the DocBook Technical Committee. Before the migration to Kavi, the
>   DocBook TC maintained an area of web space on the server containing
>   almost 4,000 individual pages. No member of the public can be
>   expected to navigate a web space of that size without some
>   navigation system for the pages that are in the space, but the Kavi
>   design offers no mechanism for such an information architecture.
>
>8. It is also simply impractical to maintain a system of that size
>   through a system that uses web forms as its user interface
>   paradigm.
>
>In addition to solving these technical issues, we feel that OASIS
>should give serious consideration to the overall design of the site.
>
>We are concerned that the current design frustrates users ability to
>quickly and conveniently find the information that they need. (Try,
>for example, to find XML Catalogs Committee Specification or the
>minutes of the second UBL meeting)
>
>This frustration, we fear, will make them less likely to return to the
>OASIS site thereby deprecating the organizations important role in the
>industry. Several TC members have already noticed this effect on
>themselves or others in their organizations.
>
>We recognize that technical committees have many different needs. Kavi
>provides facilities for electronic balloting, membership maintenance,
>and meeting scheduling that are valuable. But it is demonstrably
>inadequate in some very key ways: in the presentation of committee
>work products, in the publication of schemas and other ancillary
>materials, in the design and organization of technical committee web
>sites, and in its inability to provide reasonable looking public URIs.
>
>We close with the simple observation that these issues, both the
>technical and non-technical, are driving committees to establish
>entirely independent web sites in order to better serve their user
>communities. It would seem clear that OASIS must re-prioritize some
>staff duties and ensure that immediate, dramatic action is taken if it
>wishes to reverse this trend.
>
>Signed,
>
>The DocBook Technical Committee
>
><list of committee members>
>
>                                        Be seeing you,
>                                          norm
>
>  
>


-- 
================================================================
Scott Hudson                    Content Architect         
Sun Microsystems, Inc.          Intellectual Capital Engineering       
500 Eldorado Blvd.              Phone:(303) 272-7661
MS:UBRM06-257, Office: B086           x77661
Broomfield, CO 80021            FAX:  (303) 272-7069

Knowledge is power. Sharing is empowerment.
http://sunsolve.Sun.COM/handbook_pub/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]