Michael,
On 4/26/2010 3:37 PM, Michael Priestley wrote:
I'm fine with taking it off-list,
but
I don't expect Patrick and I to reach a common conclusion. Someone
earlier
had suggested starting a separate discussion list and allow interested
parties to sign up. I think that would have a better chance of
producing
results than a discussion that just represented two of the standards
(ODF
and DITA), and also represent perspectives that are philosophically at
very different ends of the usage spectrum (Patrick's and mine).
Patrick, I don't mean any insult by
this - but I do think we are likely to remain at odds over some of
these
questions, although I'd be happy to find us reaching a consensus
despite
my doubts.
No insult intended here as well but I think you are right about us
reaching a consensus on some of the questions.
However, rather than move the discussion off-list, let me observe that
we may have prematurely turned towards possible solutions. That is what
technical folks do, someone mentions a problem and we trot out "our"
solution to it. Including myself in that group and not, necessarily
Michael.
So, could we return to the issue that started this thread? What common
problems are there in production of OASIS standards? Without "getting
into the weeds" as Mary says with solutions?
After all, if we had a fuller understanding of the issues and their
possible causes, we might, not saying we would, decide that none of us
has a full solution to every aspect of it.
I mentioned in my response to Peter Brown several specific issues with
OASIS standards now. I am sure I have others and do many of those who
are reading this list.
Let's work towards a common listing/understanding of those problems.
That is something on which I think we might be able to reach consensus.
This list is a very appropriate place to talk about problems with the
current production process for OASIS standards.
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
Hi Michael Patrick,
This discussions seems to have gotten down into
the weeds - might I suggest that the two of you continue this off-line
and then maybe could report back with any recommendations you might
have?
Regards,
Mary
On Apr 26, 2010, at 2:12 PM, Michael Priestley wrote:
Hi Patrick,
>True and I suspect other TCs (I can think of one in particular, ;-)
) would have other preferences for the basis for the tool chain.
Absolutely. I'm in favour of supporting toolchains for other standards
as well. I'm immediately concerned for DITA, though, for which we
already
have a solution but no ability to use it without OASIS endorsement.
>Granting that in theory and some practical cases your round
tripping
argument is valid,
>but my question is would those come up in editing OASIS standards?
Assuming the use
>of templates, restricted sets of styles, etc.
I can say that in the case of the DITA spec it almost certainly would,
and I believe other standards bodies using DITA have reached similar
conclusions.
One of the reasons to choose a standard like DITA is to enable reuse
and
conditional processing, which go beyond issues of simple style.
That said, it might be possible to set up something like the Word
plugins
for DITA for OpenOffice as well. That would allow a range of desktop
editing
choices, as well as browser-based editing. The plugin would both
validate
the use of styles (preventing, for example, the movement of a title
into
the middle of a paragraph...) and extend functionality to enable the
standard
(providing conditional processing for different audiences, reuse of
content,
etc.). I'm not sure how much work it would be to create such a plugin
for
OpenOffice though.
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:
|
chairs@lists.oasis-open.org
|
Date:
|
04/26/2010 09:40 AM
|
Subject:
|
Re: [chairs] Practical
considerations
and impacts of mandated editing formats /tools |
Michael,
On 4/26/2010 9:13 AM, Michael Priestley wrote:
Hi Patrick,
I don't know if the situations you describe would hit the rules - they
are all examples of OASIS setting the tools direction.
Ah, ok.
What I do know is that if a single TC tried to do this - setting up the
software on their own, storing the content on a non-OASIS server, and
only
copying the source over to the OASIS source control - that is not
allowed.
Sure, but that isn't because of remote hosting. It is because
access/work
isn't being governed by OASIS IPR rules.
I've previously had email conversations with Mary and others about
setting
up a solution like this, and the response I got was (and I look to Mary
for corrections)
- a TC cannot set up its own source control system
- OASIS will not support a new system that is only useful to a few TCs
Sure.
For the DITA TC, we'd love to have a single system that let us develop
the spec, review it internally, and publish. We have the technology -
and
the WYSIWYG editor - what we lack is a compelling statement of interest
from other TCs.
True and I suspect other TCs (I can think of one in particular, ;-) )
would
have other preferences for the basis for the tool chain.
It was mentioned that MS Word has add-ons that handle DITA. Realizing
the
differences in enforcement that we discussed earlier, I wonder if given
the simplicity of an OASIS standard format, if it would be possible to
fashion both MS Word and OpenOffice interfaces to an online system?
Granting that in theory and some practical cases your round tripping
argument
is valid, but my question is would those come up in editing OASIS
standards?
Assuming the use of templates, restricted sets of styles, etc.
The reason I suggest MS Word and OpenOffice is that they would cover a
significant percentage of the tools in actual use, assuming that some
provision
was made for the use of both IE and FireFox on Windows and Macs for
lesser
duties.
Even though I have a Linux box networked into my current display, the
question
is accommodating a reasonable majority of users and not all users. The
latter being a very difficult and costly target. If anyone who is
excluded
wants to pony up the money to extend the coverage, feel free. I am sure
OASIS would appreciate the funds.
Hope you are at the start of a great week!
Patrick
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Michael,
On 4/23/2010 2:17 PM, Michael Priestley wrote:
I would definitely agree. I'm certainly not proposing a required
approach
- just hoping to see if there is enough interest to justify asking
OASIS
to support this approach at all. A cloud-based or web-hosted approach
is
simply not possible, according to the rules of OASIS, without OASIS
providing
the hosting. So although I'd love to be doing this today with DITA,
we can't unless more teams are also interested, enough so to justify
OASIS
supporting it.
Sorry, what OASIS rules require OASIS to host the solution?
Do you mean if OASIS leased a server at a remote hosting facility and
the
server was maintained and serviced by the hosting facility that would
be
a violation of OASIS rules? What if the software was maintained at the
direction of OASIS?
If that is the rule then it needs to be changed.
A pointer to the rule that is the problem would be appreciated.
Thanks!
Patrick
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
From:
|
"David RR
Webber \(XML\)"
<david@drrw.info>
|
To:
|
Michael
Priestley/Toronto/IBM@IBMCA
|
Cc:
|
chairs@lists.oasis-open.org
|
Date:
|
04/23/2010 02:02 PM
|
Subject:
|
RE: [chairs] Practical
considerations
and impacts of mandated editing formats /tools |
Michael,
In principle I like the idea of hosting solution. The world is going
cloud based collaboration tools.
But as Jacques noted - this should be a gradual transition where that
value
proposition sells itself - because obviously todays desktop environment
has significant strengths and benefits and we don't want to lose that
overnight.
Thanks, DW
-------- Original Message --------
Subject: Re: [chairs] Practical considerations and impacts of mandated
editing formats /tools
From: Michael Priestley <mpriestl@ca.ibm.com>
Date: Thu, April 22, 2010 5:49 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: chairs@lists.oasis-open.org
I don't disagree with your conclusion - I agree with empowering TCs to
choose their own tools. I will add a wrinkle to your argument, however:
in the case of XML authoring, there is an alternative to having to
install
custom tooling, non-default plugins, etc. Go with a hosted solution
instead.
For example, we're using a DITA-based wiki within IBM to enable
developers
and other content contributors to create DITA content without
installing
a full XML toolchain. There is some training, but I don't think
substantially
more than there would be with a new Word template or other non-XML
solution,
and with even less technical overhead.
So the subject matter experts and occasional authors use a no-install,
fast-learning-curve tool, and the power users can install a full tools
chain with more power, complexity, and learning curve. The XML
underneath
doesn't care :-)
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
My experience with this in the past is that this imposes an
unacceptable
barrier to the volunteers who do the hard work of actually editing and
completing the specifications.
Once you start needing to install add-ins and scripts and all kinds of
non-default pieces into editing tools things rapidly get out of
control.
What one person sees in their environment is not what someone else
has.
I always hear "well it works wonderfully for our TC" - but then
those same people are not the ones responsible for fixing your PC and
editor
and documents and providing support to your deadlines. Or working
with a TC member who is likewise being challenged sending in edits.
Training
is another issue.
I'd strongly prefer to not open this whole can of worms - and allow TCs
to continue tp decide - as now - what tools they are most comfortable
with
using for developing their specifications. If something is suggested
and provided to assist - that's fine - but that's not the same as
mandating
something.
DW
--
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)
|