- From: Dimitris Dimitriadis <dimitris@ontologicon.com>
- Date: Fri, 17 Jan 2003 08:58:15 +0100
- To: www-qa-wg@w3.org
- Cc: ot@w3.org
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