- From: Lofton Henderson <lofton@rockynet.com>
- Date: Sun, 19 Jan 2003 18:22:28 -0700
- 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? -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 Monday, 20 January 2003 09:56:43 UTC