Re: [chairs] What can Standards Development / TC Administration doto help?

[Patrick Durusau <patrick@durusau.net>]

Peter,

On 4/23/2010 12:07 PM, Peter F Brown (Pensive) wrote:
> Could someone clearly sum up what is broken and requires fixing?
>
> The initial post included a range of ideas from staff to improve TC work. We are now discussing the (de-)merits of an XML editing suite.
>
>    
I am rushed but here are two:

1) URLs in *published* specs are routinely broken. (i.e., there is no, 
repeat no uniform proofing of links prior to publication)

Q: How difficult is it to use a free link checker and the correct any 
errors?

2) The citation of standards in OASIS standards ranges from non-existent 
standards (literally) to cited well known standards several different ways.

Q: How difficult is it to verify the correct citation for a standard?

Here's a bonus one:

3) There is no *enforced* QA step for publications prior to TC or OASIS 
ballots nor is there a complete set of what a publication must or must 
not do in order to pass the QA step. Note I said *enforced* and I mean 
literally that. Don't pass QA = Don't get to vote on it. Quality is not 
a TC level issue. It is an OASIS branding issue.

I will try to look over my notes on reviews from just the last year to 
give you more examples of what is *broken* in the current system.

I would not characterize these issues as "improving TC work" as 
standards with broken links, inconsistent if not non-existent citations, 
arbitrary use of control language, etc., are symptoms of a *broken* 
process. (full stop)

This is an *OASIS* level issue because every specification/standard that 
bear the OASIS brand with these and other problems, *diminishes* the 
stature of the work by TC who really do work hard to get their work right.

Hope you are looking forward to a great weekend!

Patrick



> Peter
>
> -----Original Message-----
> From: Robin Cover [mailto:robin@oasis-open.org]
> Sent: Fri, 23 April 2010 08:54
> To: Frederick Hirsch
> Cc: ext Mike Edwards; chairs@lists.oasis-open.org; Mary McRae
> Subject: Re: [chairs] What can Standards Development / TC Administration do to help?
>
> On Fri, 23 Apr 2010, Frederick Hirsch wrote:
>
>    
>> Example:
>>
>> An example of how new tools can evolve is the new emerging use of ReSpec in
>> W3C, not mandated by the organization. This is HTML 5 with special markup
>> that is processed within the browser by Javascript to create all the markup,
>> boilerplate etc automatically, including shared bibliographic references and
>> formatting. Makes editors life much easier, while also enabling conformance
>> to organizational publication rules and style. (Previous efforts to
>> hand-craft HTML or use XML in a build environment were not very editor
>> friendly)
>>
>> No makefile, no build, no special tools other than support for Javascript in
>> the Browser and the use of HTML 5.
>>
>> I'm not saying this is the tool for OASIS, but an example of grass-roots
>> adoption of a tool to ease editing and publication to solve this sort of
>> problem (thanks to Robin Berjon for creating it). I understand a v2 is in the
>> works.
>>
>> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>      
> Thanks, Frederick.  Indeed, W3C has an extensive set of tools (and a couple different
> tool chains) to assist spec authors/editors in writing specifications,
> automatically including correct citations and references (using a citation-
> picker that addresses a bibliographic database), etc.  I think it's relatively
> easier to create tools for documents that use descriptive markup than
> for word-processor files.  Well... easier for most people.
>
> Anish Karmarkar [Anish.Karmarkar@oracle.com] notes the benefits
> of using the W3C environment, but mentioned that use of the
> XML Spec tool chain can require (or did, at one time) a bit of
> a learning process:
>
>     The biggest issue that I found in w3c (this was a few years
>     ago and things may be better now), in working in XML and
>     using XSLTs to generate HTML was that the diff-ing of the
>     output (HTML) was woefully inadequate. So when an editor
>     made large scale changes, it was hard for the WG members to
>     figure out exactly what changes were made by looking at the
>     HTML.
>
> http://lists.oasis-open.org/archives/chairs/201004/msg00053.html
>
> But in recent times, the W3C Staff have provided additional tools
> for generating colored diffs, and these are regularly published
> as non-normative format:
>
> http://xml.coverpages.org/specProduction.html#w3c-html-diff
>
> More broadly speaking: both W3C and IETF have built up considerable
> resources for using structured information standards (e.g., XML, XSLT,
> CSS, XHTML) in the authoring, QA checking, and publication process.
> It's a chicken-and-egg problem, though: nobody wants to support
> the development of tools they believe might be too difficult to use.
> Some 18,000 people in IETF use the IETF tools without (? much)
> complaint, and that includes several key XML tools.  Naturally,
> someone can point out that IETF people and specs are different....
>
> Everyone is probably familiar with the W3C Validiation Tools,
> including the Link Checker, which I strongly recommend for use
> by OASIS TCs where the editors do not have local-computer tools:
>
> http://validator.w3.org/checklink
>
> For a survey (not up-to-date) of W3C and IETF tool chains based
> upon standards, please see:
>
> http://xml.coverpages.org/specProduction.html#w3c
> http://xml.coverpages.org/specProduction.html#ietf
>
> If we set some goals (viz., requirements), we might be able to
> conscript more OASIS members who have coding talent to help
> improve the OASIS spec-production tools.  I note for example,
> that one member of an OASIS TC maintains a tool for XSLT
> transformation of concert RFC 2629-compliant XML (see [RFC2629])
> to various output formats, such as HTML, PDF, CHM.
>
> http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html
>
> Finally: some of the desiderata mentioned in this 2010-04 thread have
> been incorporated (months ago) into the formal requirements for
> an OASIS document management system -- while languishing in
> the execution, this system should provide a range of workflow
> and automation tools for support of specification authoring,
> editing, reviewing, QA checking, and publication (viz., through
> the entire specification lifecycle).  Send email if you would
> like to become involved in that design and development
> activity.
>
>    - Robin
>
> Robin Cover
> OASIS, Director of Information Services
> Editor, Cover Pages and XML Daily Newslink
> Email: robin@oasis-open.org
> Staff bio: http://www.oasis-open.org/who/staff.php#cover
> Cover Pages: http://xml.coverpages.org/
> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> Tel: +1 972-296-1783
>
>    
>>
>>
>> On Apr 23, 2010, at 3:10 AM, ext Mike Edwards wrote:
>>
>>      
>>> Folks,
>>>
>>> If an XML publication format is proposed, what are the tools that you
>>> expect the folks
>>> developing the specs to use?
>>>
>>> There is no point in automating the back end of the process if we make the
>>> front end of
>>> the process slower.
>>>
>>> Yours,  Mike.
>>>
>>> Strategist - Emerging Technologies, SCA&  SDO.
>>> Co Chair OASIS SCA Assembly TC.
>>> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
>>> Phone&  FAX: +44-1962-818014    Mobile: +44-7802-467431
>>> Email:  mike_edwards@uk.ibm.com
>>>
>>>
>>> From:
>>> Bob Freund<bob.freund@hitachisoftware.com>
>>> To:
>>> Dave Ings<ings@ca.ibm.com>
>>> Cc:
>>> Mary McRae<mary.mcrae@oasis-open.org>, "chairs@lists.oasis-open.org"
>>> <chairs@lists.oasis-open.org>
>>> Date:
>>> 22/04/2010 17:41
>>> Subject:
>>> Re: [chairs] What can Standards Development / TC Administration do to help?
>>>
>>>
>>>
>>>
>>> How much of this review might be automated?
>>> might be a lot if we had an xml publication format.
>>>
>>> On Apr 22, 2010, at 9:24 AM, Dave Ings wrote:
>>> +1
>>>
>>> This would really cut down on the iterative churn that seems to frustrate
>>> the people involved in the publication process. Great idea!
>>>
>>> Regards, Dave Ings,
>>> Emerging Software Standards
>>> Email: ings@ca.ibm.com
>>> Yahoo Messenger: dave_ings
>>>
>>> <graycol.gif>Hanssens Bart ---2010/04/22 09:02:30 AM--->  Would you like us
>>> to review your specifications prior to TC ballots so you don't need to go
>>> back a
>>>
>>> From: Hanssens Bart<Bart.Hanssens@fedict.be>
>>> To: Mary McRae<mary.mcrae@oasis-open.org>, "chairs@lists.oasis-open.org"
>>> <chairs@lists.oasis-open.org>
>>> Date: 2010/04/22 09:02 AM
>>> Subject: RE: [chairs] What can Standards Development / TC Administration do
>>> to help?
>>>
>>>
>>>
>>>
>>>
>>>
>>>        
>>>> Would you like us to review your specifications prior to TC ballots so you
>>>> don't need to go back and fix stuff afterwards?
>>>>          
>>> That would be very helpful indeed, especially for new TC's / people
>>> submitting specifications for the first time...
>>>
>>>
>>> Best regards
>>>
>>> Bart
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>        
>>      
>    

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)