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

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