On Fri, Feb 23, 2007 at 09:13:11AM -0500, G. Ken Holman - ISO/IEC JTC 1/SC 34 Secretariat Manager wrote:
>
> And submissions are always welcome, though the
> act of submitting something does not mandate that
> it be implemented. Submitting something makes it
> citable for discussion and reference, it does not make it policy.
Of cause, it was only my suggestions for the committee, to use at their
lesiure.
> >I offered the follwing observations in N735:
> >
> >Now that the ODF standard has been approved as IS 26300, how do we
> >proceed with the next versions of the standard?
>
> In response to the receipt of your document N735
> and questions that arose from readers of your
> document I wrote to JTC 1 for clarification and posted their answer:
>
> http://www.jtc1sc34.org/repository/0764.htm
>
> As OASIS has been designated the maintainer of
> 26300, the situation appears very clear to me,
> and I am unsure why all of this debate is being
> raised at this time. I thought this was all
> brought out in the discussions and the papers posted from mid-2006.
It seems to me less than optimal, given that a number of member bodies
are in the process of implementing IS 26300 as national standards.
To me maintenance of IS 26300 and its national implementaions could
turn out to be a nightmare.
Also I had not understood that the maintenance was a done deal and
allocated to OASIS. This may be my fault. But I would have expected this
be something that would be discussed in SC34 before a decisionn was
made, given that there had been interest in discusing it in SC34.
My understanding was that N735 was well received in SC34, and there was
quite some sympathy for the opinions raised there, but of cause no
decision on the matter.
> >The DIS ballot resulted in comments of about 20 pages, as contained in
> >SC34 N0728. These comments needs to be addressed, and most likely the
> >final IS 26300 will be changed from the ballotted document. Thus there
> >will be two different standards for ODF, the OASIS standard and the
> >ISO/IEC standard. This is not at good situation.
>
> I cannot understand why you state there will be
> two different standards. This is going to be
> very confusing and detrimental for people to read
> you say this. The procedures are clear, the
> maintainer is OASIS, and there will only be one version of 26300.
There will be an OASIS standard, different from IS 26300.
This will confuse the marketplace.
> Continuing to entertain notions of proceeding in
> a fashion contrary to the JTC 1 Directives
> promotes an attitude that SC34 does not follow
> established rules. Why is this established
> process being questioned, and so publicly, by members of SC34? I'm
> confused.
Why do you say it is very public? I only know of discussions on this
email list, which is our internal email list.
> >What can be done about this?
>
> We can follow JTC 1 procedures is what can be done about this.
JTC 1 procedures allows implementations in various ways.
My initial question was what could be done to avoid both an OASIS
atandard and an ISO standard to exist, with some confusing minor
differences.
> >I see 3 scenarios:
> >
> > 1. Leave it as is, and OASIS can go forward with the revision and
> >submit their standard as PAS for the next edition. This will result in a
> >number of different standards from OASIS and ISO, and make implementers
> >a bit confused on which standard to implement.
>
> I don't see how ... OASIS is the maintainer.
I am just reproducing N735, which was written before the OASIS
arrangement was made. Please read my document in the spirit it was
written in.
> > 2. OASIS can take the resulting ISO standard back in their process,
> >and hope that an OASIS ballot will not resolve in changes to the new
> >OASIS standard. This will establish one standard, but it is likely that
> >the changes to the 1.0 standard will be small, and that it will lead to
> >market confusion which version of the standard to implement. It is also
> >possible that the OASIS process introduces new changes.
>
> OASIS is the agreed-upon maintainer so SC34
> should submit any and all issues to OASIS. This
> was *further* clarified in the correspondence from JTC 1 received last week.
>
> At 2007-02-23 12:37 +0100, Keld Jørn Simonsen wrote:
> >3. Maintain the standard jointly between
> >OASIS and SC34. There is a model for it
> > in how the POSIX operating system standard is being maintained in
> > SC22, recorded in SC34 N0587.
>
> But that is not what we have been directed to do
> by JTC 1, nor does it mesh with the agreement
> between JTC 1 and OASIS when OASIS submitted
> their document for the PAS process.
>
> >I thus recommend that we use the common maintenance model recorded in SC34
> >N0587.
>
> I understand that you recommended that, and I
> followed up to determine what the possibilities
> are, and I've long published the documents supporting the current situation.
Which IMHO is quite problematic. So we could discuss if the arrangement
could be changed.
> >Similar steps can be done for RELAX NG and other projects.
>
> Why say this now? RELAX-NG, NVDL and the other
> parts of DSDL all went through the complete ISO
> process and are ISO documents, not the documents
> of any FT or PAS submission. These are
> maintained in SC34 as are all other SC34
> standards that originate in SC34 regardless of
> their genesis before they become part of our process.
I am just opening up the process to W3C if they are interested here.
My aim is to cooperate, so that organizational tensions can be
eliminated. Quite some energy can be bound in such battles, for no
reason. Believe me, I have been there.
> We are spending an awful lot of energy on issues
> we cannot change and trying to get around procedures by which we are bound.
We may also spend an awful lot of energy with the current arrangement,
plus confuse the marketplace. It is much easier if we cooperate.
> As the Secretariat, I'm feeling incredibly
> compromised by what appears to be a mutiny of
> SC34 members to established JTC 1 process. We
> have accepted the process and procedures by which
> the standards are developed, it is not helping to
> propose contrary behaviours that SC34 will have
> to try and justify, but have no basis for
> justification. If members are asking me to take
> revised SC34-proposed procedures to JTC 1 that
> are contrary to the JTC 1 procedures just for
> SC34 projects, I'm going to be laughed at by JTC 1.
What is being discussed here is not contrary to JTC 1 procedures.
But of cause it would remove some control from OASIS, and they
may be hesitant about this.
> Besides, this is a volunteer effort to run the
> Secretariat and it doesn't seem a very good use
> of my limited time to be pushing against the
> current to do things against established
> procedures we've already agreed to follow.
We did not decide in SC34 how we wanted to maintain IS 26300.
> There are ongoing JTC 1 ad hoc meetings regarding
> Directives. Keld is the SC34 representative in those meetings.
>
> We are bound by JTC 1 rules, and I'm trying to
> administer those rules for this group. That is what you asked me to do.
Agree. I don't see how the discussion here would be contrary to that job.
I believe that doing some work on a versatile arrangement for
maintenance of IS 26300 can save us quite some problems in the future,
and reduce confusion in the marketplace considerably. And it can
strenghten SC34 a little, in getting our standards to be used,
as they will not always be outdated in comparison to the OASIS versions.
And it can reduce the workload. It is easier to maintain just one
version (both OASIS and ISO) than maintaing two.
best regards
keld
-- DSDL members discussion list To unsubscribe, please send a message with the command "unsubscribe" to dsdl-discuss-request@dsdl.org (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)Received on Sat Feb 24 00:18:14 2007
This archive was generated by hypermail 2.1.8 : Sat Feb 24 2007 - 02:13:02 UTC