At 2007-02-23 12:20 +0100, Keld Jørn Simonsen wrote:
>Could we have this subject on the agenda for the SC34 plenary?
I suppose ... though I believe we have already been given clear direction.
>I did submit a paper on coordination of different versions of standards
>both with SC34 and then in other organizations. The idea is that we
>produce as few slightly differing versions of a standared as
>possible.and also that we get the standards published in the different
>organizations as possible.
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.
>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.
>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.
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.
>What can be done about this?
We can follow JTC 1 procedures is what can be done about this.
>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.
> 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.
>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.
We are spending an awful lot of energy on issues
we cannot change and trying to get around procedures by which we are bound.
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.
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.
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.
. . . . . . . . . . . . . . Ken
-- G. Ken Holman Crane Softwrights Ltd. ISO/IEC JTC 1/SC 34 Secretariat Standards Council of Canada Committee correspondence: mailto:jtc1sc34@scc.ca Committee website: http://www.jtc1sc34.org Corporate correspondence: mailto:gkholman@CraneSoftwrights.com Corporate website: http://www.CraneSoftwrights.com/a/ -- 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 Fri Feb 23 15:15:18 2007
This archive was generated by hypermail 2.1.8 : Fri Feb 23 2007 - 23:23:03 UTC