[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [chairs] What can Standards Development / TC Administration do to help?
hi, One more very important requirement to keep in mind: Once the "volunteer" who authored the spec has long since gone, OASIS (staff) will have to maintain and be able to edit the source files for the specs. Essentially, this amounts to saying that organizational costs and requirements also have to be factored in. This is one of the reasons why OASIS, the organization, can not really tolerate 100's of TCs producing 1000's of documents/specs, all in a different format. I am NOT saying that "one size fits all" has to be the order of the day, but i am saying there has to be a reasonably small number of acceptable formats. There should be a enough flexibility so that folks have a reasonable chance of finding a production methodology for their TC that fits their comfort level, but not necessarily their "perfection" level; and that balances the OASIS organizational requirements. (uniform look/feel, maintainability, low staff overhead, etc.) We should also be able to have enough automated checking of requirements that we get scalability as the number of TC's and specs goes up. This is most certainly not the case today. There is far too much hand/custom checking that has to be done by OASIS staff, which is partially responsible for the frustrations and delays some TCs encounter in trying to move from adopting a motion to have a public review/CS ballot to actually being able to open the PR/CS vote. cheers, jeff On Apr 22, 2010, at 3:56 PM, Bob Freund wrote: > That can easily be changed, flexibility comes at the cost of > scalability. > The point is to balance ease of authoring, ease of automated > verification and error checking, and flexibility in output format > coupled with consistency in appearance. > In the end it matters little what authoring tool is used as long as, > in an xml format, a normative reference is decorated just so, and > the editors are decorated just so, and the copyright so and so-forth. > =bob > > On Apr 22, 2010, at 4:41 PM, MARTIN.CHAPMAN@ORACLE.COM wrote: > >> Oasis allready allows a TC to author specs in any format for which >> a template exists. And if a template doesn't exist you can request >> one. >> >> Martin >> >> Sent from my iPhone >> >> On 22 Apr 2010, at 20:44, Michael Priestley <mpriestl@ca.ibm.com> >> wrote: >> >>> >>> Patrick wrote: >>> >Those are output formats. Why would we limit users to just one? >>> >>> None of those are output formats. And authoring in any one of them >>> is mutually exclusive with the others. You can only have one >>> source format. >>> >>> OpenOffice editors may be capable of reading ODF into memory, and >>> then outputting to other models - but that is not the same as >>> authoring in that model. For example ODF allows formatting >>> instructions in source that deliberately have no equivalent in >>> DocBook or DITA. And both DITA and DocBook have semantic and >>> structural requirements that cannot be enforced in a general- >>> purpose word processor. >>> >>> If we created equivalent stylesheets for DocBook and DITA, we >>> should be able to get a common look and feel from those two >>> different source formats. To accomplish the same end in ODF would >>> require a different approach, I believe, using authoring templates >>> and guidelines rather than schema rules and stylesheets. >>> >>> I think it would be wonderful if OASIS allowed authoring of its >>> specifications in any of its standardized document formats. Then >>> TCs can make their own choice of source format based on the >>> capabilities they require, and produce a common look and feel that >>> still supports the needs of the OASIS brand. >>> >>> Michael Priestley, Senior Technical Staff Member (STSM) >>> Lead IBM DITA Architect >>> mpriestl@ca.ibm.com >>> http://dita.xml.org/blog/25 >>> >>> >>> From: >>> Patrick Durusau <patrick@durusau.net> >>> To: >>> bryan.s.schnabel@tektronix.com >>> Cc: >>> mary.mcrae@oasis-open.org, Bob.Freund@hitachisoftware.com, Dave >>> Ings/Toronto/IBM@IBMCA, chairs@lists.oasis-open.org >>> Date: >>> 04/22/2010 02:56 PM >>> Subject: >>> Re: [chairs] What can Standards Development / TC Administration do >>> to help? >>> >>> >>> >>> >>> Bryan, >>> >>> On 4/22/2010 1:17 PM, bryan.s.schnabel@tektronix.com wrote: >>> Yes! I'd love it. But I can already begin to see the battle lines >>> being drawn, i.e., which one (DITA, Docbook, OpenDocument, . . .)? >>> >>> Those are output formats. Why would we limit users to just one? >>> >>> Even though as the ODF editor I would prefer that everyone output >>> to ODF, I can understand why others feel equally strongly for >>> their output formats. >>> >>> The real fight would be over a uniform format. The underlying >>> representation that is output is a detail. An important one but >>> still just a detail. >>> >>> Personally I would welcome an activity to declare meaningful rules >>> for formatting OASIS standards, provided those rules were enforced. >>> >>> If nothing else, it would make the main work product of our >>> committees have some appearance of issuing from the same >>> organization (other than the cover pages). >>> >>> Hope you are having a great day! >>> >>> Patrick >>> >>> >>> From: Mary McRae [mailto:mary.mcrae@oasis-open.org] >>> Sent: Thursday, April 22, 2010 9:58 AM >>> To: Bob Freund >>> Cc: Dave Ings; chairs@lists.oasis-open.org >>> Subject: Re: [chairs] What can Standards Development / TC >>> Administration do to help? >>> >>> Agreed. How would the chairs feel about mandating all specs be >>> created in an OASIS XML format? >>> >>> m >>> >>> On Apr 22, 2010, at 12:40 PM, Bob Freund wrote: >>> >>> >>> 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 >>> >>> >>> >>> -- >>> 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) >>> >>> >>> > -- Jeff Mischkinsky jeff.mischkinsky@oracle.com Sr. Director, Oracle Fusion Middleware +1(650)506-1975 and Web Services Standards 500 Oracle Parkway, M/S 2OP9 Oracle Redwood Shores, CA 94065
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]