Michael,
On 4/22/2010 5:26 PM, Michael Priestley wrote:
OF407B1AA3.2C75AB9A-ON8525770D.0073ED37-8525770D.0075C706@ca.ibm.com"
type="cite">
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?
OF407B1AA3.2C75AB9A-ON8525770D.0073ED37-8525770D.0075C706@ca.ibm.com"
type="cite">>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.
OF407B1AA3.2C75AB9A-ON8525770D.0073ED37-8525770D.0075C706@ca.ibm.com"
type="cite">>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?
OF407B1AA3.2C75AB9A-ON8525770D.0073ED37-8525770D.0075C706@ca.ibm.com"
type="cite">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
OF407B1AA3.2C75AB9A-ON8525770D.0073ED37-8525770D.0075C706@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
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
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)
|