Re: Document Technology Survey, Comment Deadline 20030129

Overall, I think this will make a nice and useful report when formatted 
(some headings, bullet lists, etc).  My comments are few and simple:

First, I suggest that the questionnaire be put at the end, and there could 
be a forward reference to it from the beginning.

Other comment(s) embedded...

At 03:40 PM 1/24/03 +0100, Dimitris Dimitriadis wrote:

>QA WG,
>
>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.

We should talk about this -- putting the table of raw responses, which has 
individuals' names, into a public area.  I think it is NOT a good idea, 
unless we clear it with our responders.  That would be a pain.  (note 
however... I can't remember what level of confidentiality we promised about 
the raw results -- does anyone else remember?).

Actually I think the summary is quite thorough, and I'm not sure that we 
need to expose the raw data to the public.  Maybe it is not even 
interesting to members (altho' it is now member-readable if they can find it)?

What do others think?

>Please provide feedback, if any, before I post this to the chairs list and 
>QA IG, before January 29.
>
>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

Units?  I.e., % of what?  Also, I'm slightly confused what this 
summarizes.  Something in Question #5.  But I notice now that the last 
choice item of #5, i.e., the last "[]", actually looks more like a 
sub-question of the main question (not a choice).  The sentence introducing 
the above statistics seems to talk about start-up time, which is that last 
"[]".  But the units of the latter are "hours", not percentage.

So a little disambiguation might be in order here.

>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, 27 January 2003 19:26:33 UTC