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