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] Practical considerations and impacts of mandated editingformats /tools



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.

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

From: "David RR Webber \(XML\)" <david@drrw.info>
To: chairs@lists.oasis-open.org
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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]