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: Draft Kavi message


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

-- 
Norman Walsh <ndw@nwalsh.com>      | Computer Science is the first
http://www.oasis-open.org/docbook/ | engineering discipline in which
Chair, DocBook Technical Committee | the complexity of the objects
                                   | created is limited solely by the
                                   | skill of the creator, and not by
                                   | the strength of raw materials.--B.
                                   | Reid


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