[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [chairs] What can Standards Development / TC Administration doto help?
Mary, Then perhaps my disagreement is the the low bar for the QA test. I would think that not being required to have: 1) All links working? Everywhere. (how hard is that?) 2) Proper use of control language. (Admittedly, that would take an actual reading of the document and so would be resource intensive.) 3) Proper citation of other standards. (The TAB has a project that is moving slowly on that issue.) represents far too low a bar for anything that merits the term "standard." Document management/workflow will help, but what is really necessary is the political will to hold *our* collective feet to the fire with regard to quality. No document management/workflow system can enforce rules we are unwilling to make ourselves live by. Hope you are at the start of a great weekend! Patrick On 4/23/2010 2:16 PM, Mary McRae wrote: > Just a point of disagreement - there IS a complete and enforced list of what a spec must or must not do in order to pass the QA step. The checklist can be seen here: http://docs.oasis-open.org/templates/QAChecklistV3.html. Any specification submitted for public review or committee specification ballot must first pass the QC check. Since CS are balloted for OS, there's no additional check required at that point since the documents are identical. Patrick is correct in that no check is required at this point in time for CD; once we have a doc management/workflow system this would be integrated at that level as well. > > I strongly encourage all TCs to take advantage of the checklist as well as the video tutorial to make sure their specifications will pass the QC checklist prior to submission; barring that, I offered a suggestion that Stds Dev would check specifications prior to the TC approving them - this could be done well in advance; I think most TCs know when they're getting fairly close to a specification approval milestone. > > Note that the checklist is a minimum bar; we do not currently check internal cross-references, links other than those on the cover page and references to other OASIS work. > > Another service we could potentially add would be performing that additional (but not required) level of QC. > > Mary > > > On Apr 23, 2010, at 1:41 PM, Patrick Durusau wrote: > > >> 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) >> >> > > -- 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]