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: One more thought: was Re: [chairs] What can Standards Development/ TC Administration do to help?


Michael,

It occurred to me this morning that it may be the packaging aspect of ODF that gives the impression that it is fundamentally different from DocBook or DITA.

That is to say that in order to have a published output of either DocBook or DITA, one uses stylesheets. Yes?

Well, the same is true for ODF except that ODF has the stylesheets packaged up with the markup file.

As I said, I haven't compared the content models, that is the content.xml part of ODF with DITA or DocBook but I would be very surprised if they are completely different. There are only so many ways to talk about document structures (at least in the Western tradition) and I suspect there is more commonality than difference.

There are differences and at the level of abstraction that I usually work at (when not editing ODF), they are all models. Pick whichever one suits your purpose. What other criteria would there be? (I confess to getting annoyed when ODF is portrayed as difficult or hard when only seen through a user interface.)

Hope you are looking forward to a great weekend!

Patrick


On 4/22/2010 6:26 PM, Michael Priestley wrote:
OF68DF201F.C73D6335-ON8525770D.007A1959-8525770D.007B41F4@ca.ibm.com" type="cite">
Hi Patrick,

You wrote:

>True, you can't edit it in OpenOffice but I am not sure what that proves? Perhaps I am missing your point?

You can distinguish the source format from the other formats by the ability to edit it :-) (And also, the ability to generate the others from it)

>That is a common assumption, that "underlying capabilities and structures are not reliably round-trippable" but other than seeing it said, I haven't ever seen an example of it.

I've seen a thousand examples. DITA and everything else :-)  As a very simple example, <title> is required in DITA, and font information is excluded. So if I move a DITA topic into OpenOffice, delete the title and add fonts, I cannot get back. Then there's the reuse relationship - I don't know whether ODF has a standardized equivalent of the DITA conref attribute.

>Actually ODF does preserve the separation of content from style as the content is held in a separate file (within a package) to which styles are applied

There is clearly a continuum. DITA pushes a lot more font stuff out of the document, and imposes a lot more structure and semantics in the element and attribute choices. HTML is probably somewhere in the middle.  But I hope you're not going to say that ODF is as presentation-free as DITA or DocBook.

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

>Since both are already being used to develop and publish OASIS standards, I think their relevancy is established fact, not an assumption. The work of mapping DocBook and DITA >models to OASIS document outputs (using stylesheets) has already been accomplished (or, in the case of DITA, is at least nearly so).

>Err, the question wasn't the relevance of either DITA or DocBook

You asserted that the semantic and structural requirements of DITA and DocBook could not be known to be relevant to the OASIS model, because the OASIS model is unknown. I pointed out that since both DITA and DocBook are already producing specifications that conform to the OASIS model, their requirements can be known to be relevant.

>You said that there were semantic and structural requirements of both that would be necessary for editing an OASIS standard.

No, I said they have semantic and structural requirements that are necessary in order to produce valid DITA or DocBook. And you need valid DITA or DocBook to run the transforms that produce valid OASIS specifications.

>I pointed out in the absence of a *common model* for OASIS standards, it isn't possible to evaluate your statement.

There is a common output model. In the absence of a common source model, both DITA and DocBook are clearly already enabled and doing the job.

>Yes, both DocBook and DITA are being used to produce work products of some TCs. The question is whether all TCs are producing a *uniform* product?

As indicated in another thread, output from DocBook has already been established to be considerably more conforming than content created using Word templates. I certainly expect that the DITA package will be similarly reliable.

>My point was that we lack the specific for "any OASIS-specific structural requirements." If we had those, then we could talk about how to meet them.

I can agree on this. Hopefully, in the meantime, I've clarified why I do not think of DITA and DocBook as output formats, and why I do not think of them as reliably roundtrippable with ODF (or even each other, for that matter).

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: Michael Priestley/Toronto/IBM@IBMCA
Cc: Bob.Freund@hitachisoftware.com, bryan.s.schnabel@tektronix.com, chairs@lists.oasis-open.org, Dave Ings/Toronto/IBM@IBMCA, mary.mcrae@oasis-open.org
Date: 04/22/2010 05:44 PM
Subject: Re: [chairs] What can Standards Development / TC Administration do to help?





Michael,

On 4/22/2010 5:26 PM, Michael Priestley wrote:


Hi Patrick,


In the case of DITA and DocBook, "common look and feel" are primarily a matter of the right stylesheets to produce PDF and HTML, combined with some authoring templates and guidelines. But the authoring templates and guidelines would be specific to the underlying standard, and the content being created will have different structural rules and capabilities depending on the standard chosen.


For example, a DITA topic with a reused common paragraph:


<topic id="abc">

       <title>ABC section of spec</title>

       <shortdesc>The ABC function is for blah blah</shortdesc>

       <body>

               <p>This is something unique to ABC</p>

               <p conref="ABCrelated.dita#anothertopic/xyz"><!--this is a reused paragraph coming from somewhere else--></p>

               <p>etc.</p>

       </body>

</topic>


This topic obeys the DTD or XSD rules for a DITA topic. It uses DITA capabilities for reuse, and DITA structures for title, short description, and content. I cannot edit it with OpenOffice. I need to edit it with an XML editor that enforces these rules and enables these capabilities: whether it's a native XML editor like XMetal, Arbortext, Oxygen, etc. or a plugin-enabled Word, like Quark XML Author.


True, you can't edit it in OpenOffice but I am not sure what that proves? Perhaps I am missing your point?

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

I don't know what this means. The "source format" is the one you edit, and whose rules the editor enforces. I added the example above to make this more concrete. I think ODF and other wordprocesser-centric XML models are very different from the old-school "separate content from presentation" formats like DITA and DocBook, and I want to avoid confusion.  The underlying capabilities and structures are not reliably round-trippable.


That is a common assumption, that "underlying capabilities and structures are not reliably round-trippable" but other than seeing it said, I haven't ever seen an example of it.

Actually ODF does preserve the separation of content from style as the content is held in a separate file (within a package) to which styles are applied. Granting that some of the elements can be said to have "presentational" semantics but the separation of from structure has never been 100% in any system. Why do you think we all have a <p> element of some variety? You can say it is purely structure but I think we both know it has implied semantics.

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

Since both are already being used to develop and publish OASIS standards, I think their relevancy is established fact, not an assumption. The work of mapping DocBook and DITA models to OASIS document outputs (using stylesheets) has already been accomplished (or, in the case of DITA, is at least nearly so).

Err, the question wasn't the relevance of either DITA or DocBook

You said that there were semantic and structural requirements of both that would be necessary for editing an OASIS standard.

I pointed out in the absence of a *common model* for OASIS standards, it isn't possible to evaluate your statement.

Yes, both DocBook and DITA are being used to produce work products of some TCs. The question is whether all TCs are producing a *uniform* product?

Yes?

We could also go the route of creating a valid DITA specialization to model more closely any OASIS-specific structural requirements. DITA specializations remain valid DITA, even when the tags have been heavily customized for a particular use.

My point was that we lack the specific for "any OASIS-specific structural requirements." If we had those, then we could talk about how to meet them.

But, I think we will need to develop those first.

Yes?

Hope you are having a great day!

Patrick

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: Michael Priestley/Toronto/IBM@IBMCA
Cc: Bob.Freund@hitachisoftware.com, bryan.s.schnabel@tektronix.com, chairs@lists.oasis-open.org, Dave Ings/Toronto/IBM@IBMCA, mary.mcrae@oasis-open.org
Date: 04/22/2010 04:05 PM
Subject: Re: [chairs] What can Standards Development / TC Administration do to help?






Michael,

On 4/22/2010 3:44 PM, Michael Priestley 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.


As long as you can output to a common model in any of those formats, how would you distinguish your "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.


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.

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.

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

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)



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