Re: Document Technologies Survey

And while assigning it (or having someone take it on volontarily) could 
the WG communicate any comments/feedback before I send it to the QA IG 
list and the chairs?

Thanks

/Dimitris

On Wednesday, January 22, 2003, at 05:11  PM, Lofton Henderson wrote:

>
> 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:12:48 UTC