|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.
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.
Sent from my iPhone
>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
On 4/22/2010 1:17 PM, email@example.com
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
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!
From: Mary McRae [mailto:firstname.lastname@example.org]
Sent: Thursday, April 22, 2010 9:58 AM
To: Bob Freund
Cc: Dave Ings; email@example.com
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?
On Apr 22, 2010, at 12:40 PM, Bob
How much of this review might be
might be a lot if we had an xml
On Apr 22, 2010, at 9:24 AM, Dave
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
Yahoo Messenger: dave_ings
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 <firstname.lastname@example.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...
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)