W3C home > Mailing lists > Public > www-qa-wg@w3.org > January 2003

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

From: Lofton Henderson <lofton@rockynet.com>
Date: Sun, 19 Jan 2003 18:22:28 -0700
Message-Id: <>
To: www-qa-wg@w3.org

Thanks for the summary, Dimitris.

Before circulating ... I think it would be nice to make it into a simple 
HTML document, on our QA template, if someone were willing to do it.

Anyone ... volunteer to HTML-ize it?


At 08:58 AM 1/17/2003 +0100, Dimitris Dimitriadis wrote:

>AI-20021008-10:  Generate the feedback/statistics from document technology 
>survey and communicate it to the editors
>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
>[] 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 
><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 Monday, 20 January 2003 09:56:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:29 UTC