- From: Dimitris Dimitriadis <dimitris@ontologicon.com>
- Date: Tue, 21 Jan 2003 21:27:12 +0100
- To: Lofton Henderson <lofton@rockynet.com>
- Cc: www-qa-wg@w3.org
It would be great if someone could HTMLize the results, as I've promised QA IG to circulate that I will the results fairly soon. /Dimitris On Monday, January 20, 2003, at 02:22 AM, Lofton Henderson wrote: > > 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 Tuesday, 21 January 2003 15:27:28 UTC