OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[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?


Michael,

On 4/22/2010 3:44 PM, Michael Priestley wrote:
OF535522B3.CB6F176F-ON8525770D.006BC778-8525770D.006C649F@ca.ibm.com" type="cite">
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.

As long as you can output to a common model in any of those formats, how would you distinguish your "source format?"

OF535522B3.CB6F176F-ON8525770D.006BC778-8525770D.006C649F@ca.ibm.com" type="cite">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.

First, I am assuming there would be a common set of features, like part 2 of the ISO guide to authoring standards, which would control what structure can appear in an OASIS standard.

Second, with no model under discussion, it is your assumption that the semantic and structural requirements of DITA and DocBook would even be relevant to the *unknown* model for OASIS standards.

OF535522B3.CB6F176F-ON8525770D.006BC778-8525770D.006C649F@ca.ibm.com" type="cite">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.

Not having a known model to go by, I would speculate that authoring templates and stylesheets (which limit the users options) would be sufficient.

OF535522B3.CB6F176F-ON8525770D.006BC778-8525770D.006C649F@ca.ibm.com" type="cite">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.

So long as it results in a common output, I can't argue with how a TC gets there.

But I do think that requires agreement on what that "common look and feel" as you put it will be.

Hope you are having a great day!

Patrick
OF535522B3.CB6F176F-ON8525770D.006BC778-8525770D.006C649F@ca.ibm.com" type="cite">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)



-- 
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]