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.
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.
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
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.
Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
From:
Patrick Durusau <>
To:
Date:
04/26/2010 09:04 AM
Subject:
Re: [chairs] Practical considerations
and impacts of mandated editing formats /tools
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
http://dita.xml.org/blog/25
From:
"David RR Webber \(XML\)"
<>
To:
Michael Priestley/Toronto/IBM@IBMCA
Cc:
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 <>
Date: Thu, April 22, 2010 5:49 pm
To: "David RR Webber (XML)" <>
Cc:
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
http://dita.xml.org/blog/25
From:
"David RR Webber \(XML\)"
<>
To:
Date:
04/22/2010 05:11 PM
Subject:
[chairs] Practical considerations and
impacts of mandated editing formats /tools
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
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)
