MHonArc v2.5.0b2 -->
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]