Document Technologies Survey

This survey summary document would be nice to have in our QAWG collection 
-- a useful QAWG accomplishment to point to.  But it should be formatted on 
our QA template (XHTML).

Will someone do this please?

(Or, should the chairs assign someone?).

-Lofton.

>Resent-Date: Mon, 20 Jan 2003 09:56:44 -0500 (EST)
>X-Sender: lofton@rockynet.com
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Sun, 19 Jan 2003 18:22:28 -0700
>To: www-qa-wg@w3.org
>From: Lofton Henderson <lofton@rockynet.com>
>X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for 
>spam.
>Subject: Re: My action item AI-20021008-10 completed (and question for   Dom)
>X-Archived-At: 
>http://www.w3.org/mid/5.1.0.14.2.20030119181951.009d1290@rockynet.com
>Resent-From: www-qa-wg@w3.org
>X-Mailing-List: <www-qa-wg@w3.org> archive/latest/1410
>X-Loop: www-qa-wg@w3.org
>Sender: www-qa-wg-request@w3.org
>Resent-Sender: www-qa-wg-request@w3.org
>List-Id: <www-qa-wg.w3.org>
>List-Help: <http://www.w3.org/Mail/>
>List-Unsubscribe: <mailto:www-qa-wg-request@w3.org?subject=unsubscribe>
>X-RCPT-TO: <lofton@rockynet.com>
>
>
>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?
>
>-Lofton.
>
>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
>>
>>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 Wednesday, 22 January 2003 11:09:37 UTC