My action item AI-20021008-10 completed (and question for Dom)

AI-20021008-10:  Generate the feedback/statistics from document 
technology survey and communicate it to the editors

QA WG,

I've an action item to provide feedback an statistics from the survey 
we made on document technologies during the autumn. Dom, I'd need your 
help in directing this to the right list.

The replies were tabulated and are given in the following table: 
http://www.w3.org/QA/Group/2002/09/results-survey (member only). I 
think it is safe, after the WG has been informed, to put the table with 
comments that may result from this post in a public area. Please 
provide feedback, if any, before I post this to the chairs list.

This completes my action item AI-20021008-10.

For brevity's sake, I include the original questionnaire (which was 
sent to chairs@w3.org):

---
1. In authoring your specifications, do you use (1 choice) as format for
_authoring_ (not publishing):
[] XMLspec or variety thereof
[] XHTML
[] HTML
[] (X)HTML + div using classes to identify particular content and 
structure
[] Other, indicate:

2. If you're not using XMLspec, has your group considered it?
[] Yes, please indicate why you rejected it:
[] No, please indicate why:

3. If you're using XMLspec, is it the current distribution (v2.1 or 
v2.2), or a modified version?
[] Plain
[] Modified
        
If modified, please indicate the nature and rationale of the change. []
        
4. How do you produce your published specifications?
[] Lead editor assembles document editor parts from the editors, 
producing a master document
[] Submit parts of document, producing the master document via script 
or similar solution
[] Other (please indicate) []

5. How big a part of the editor's workload is it to stay close to a 
particular markup, if used, during the ongoing effort?
[] Less than 5%
[] 5-10%
[] 10-20%
[] More than 20%
[] Please indicate the amount of hours it takes to overcome the startup 
phase, ie. how long it (generally) takes for editors to start using the 
content structured agreed on by the WG (hours).
---

Out of the 29 replies (which is not easily translatable to an equal 
number of Working Groups, as some editors edit more than one 
specification, specification authoring technology turned out to be

XML Spec: 15
XHTML + classes: 11 (9 with classes, 2 without)
HTML (plain): 3

Given the sheer numbers, it seems to be a close call between XML Spec, 
or varieties thereof, and XHTML + classes (that could be used to 
transform the markup into XML Spec).

Of the people using XML Spec, 4 used plain XML Spec (ranging from v 1.1 
to 2.2), 11 used modified. Some have changelogs available. The 
rationales for modifying were, where given:
Modification to match namespace constraints
Need for additional functionality for function signatures and other 
special display
Customization mainly to allow additional structured information that 
was not envisaged by the DTD authors, e.g. tagging of error conditions
Custom elements to markup references to the schema for schemas and for 
markup of infoitems and properties
Augmentations to add markup needed for correctly rendering the 
copyright statement (e.g. abbr) according to the pubrules.
In the past added additional structure for issues to enable scraping 
the document into a full-featured issues list

It seems clear that XML, where used, was not judged to be sufficient 
for all authors. Therefore, any future version of XML Spec should look 
into the changes made by some WG to accomodate for those changes, and 
make a superset that can be incorporated into XML Spec. Clearly, the 
work on XML Spec needs to be coordinated so that changes are uniform 
and reusable.

Of the people using XML Spec, reports on how long it took to learn are 
as follows:

<5%: 9
5-10%: 4
10-20%: 2

It seems that once decided for, XML Spec is generally not very 
difficlut to use (especially if one uses a DTD-aware XML editor)

Of the people using XHTML, 9 used it together with extra classes, 2 
plain

Of those who had considered using XML Spec, reasons for rejecting it 
were, where given:

Considered, biggest issue is ease of authoring
No good WYSIWYG XML Editor
Didn't know about XMLSpec (5 such replies)
No time to explore it, needs very simple anyway
considered, but rejected because :
     * too much unwanted features, and too much missing wanted features
     * More familiar with HTML, more tools to edit HTML
     * conversion cost from a huge existing spec too big
not really considered; ease of authoring is a plus for XHTML
simplicity of editing, lack of XML Editor, conversion effort for XMLSpec

Except for people not knowing about XML Spec (and the benefits of using 
it, obviously), which means there needs to be an effort to make it more 
well known, ease of authoring seems to be the biggest issue (which 
could be resolved by using a DTD aware editor), together with 
transforming issues. One report of XML Spec having too many unwanted 
features and too few wanted one is also noteworthy.

Of the people using plain HTML, reports for not using XML Spec are:

Never heard of it. Would reject it as not being recognized by all UAs
No: HTML was familiar, learing XMLSpec in the time allotted for this 
task was not possible
Not had a chance to look at it. Maybe in the future

As far as editorial tasks are concerned (publishing process) reports 
are, where given:

Assembling done by the Lead Editor (14)
Editing slots fixed by emails (3)
Script (1)
CVS (3)
By hand (1)
Single editor (4)
Master document exchanged between editors (1)

There are various ways used, but it seems that the lead editor 
assembling document parts is the most frequent one. Other variants and 
combinations exist (assembling document parts from CVS, transforming 
into master version for publication and so forth). It would be 
beneficial, I think, to streamline the editing process.

Received on Friday, 17 January 2003 02:58:25 UTC