All
normative computer language definitions that are part of the
specification, such as XML instances, schemas and Java(TM) code, including
fragments of such, must be well-formed and valid, and must be provided in
separate plain text files. Each text file must be referenced from the
specification. Where any definition in these separate files disagrees with
the definition found in the specification, the definition in the separate
file prevails.
FYI, Item #3 and the section it refers to seems
to have some bearing on conformance issues we've been discussing or
commenting on in our edits.
In particular, there seems to be a requirement to
repeat every single conformance statement that occurs in the spec in a
separate section where they can be more easily reviewed
ensemble:
A specification that is approved by the TC at the Public
Review Draft, Committee Specification or OASIS Standard level must
include a separate section, listing a set of numbered conformance
clauses, to which any implementation of the specification must adhere in
order to claim conformance to the specification (or any optional portion
thereof).
Also it appears that we can now consider the DTD we supply in
separate plain-text files to be normative, and to override whatever we
actually say in the specification itself.
OTOH, it seems the same can be said about the schema files -
and it's unclear how discrepancies between the two could be
handled.
--Dana
On 31 July 2009 the OASIS Board of Directors approved a set of
revisions to the TC Process. The effective date of the new Policy is 1
September 2009 and can be seen here:
http://www.oasis-open.org/committees/process-2009-07-30.php.
A change-marked PDF copy is available upon request and will be available
on the TC Process Policy web page on or before the effective date.
The major changes are as follows:
1. Persistent Non-Voting Member. A new role has been defined,
allowing a TC Member to declare their non-voting status. The process by
which a Member makes such declaration as well as revoking it is
established. (See Definitions: x. as well as
Section 2.4.3)
2. Charter submissions. Charter submissions must now include
statements of support from the Primary Representatives of Organizational
Members listed as co-proposers. They will also be notified if the Charter
submission is amended in any way. (See
Section
2.2)
3. Schemas, XML instances, etc. associated with a specification. The
Process now explicitly states that if a discrepancy occurs between the
plain text file and the specification document, the definition in the
separate file prevails. (
See
Section 2.18)
In addition, some smaller changes were made in an attempt to clarify
some potentially confusing language:
4. Explicitly state that all notifications to the OASIS TC
Administrator must be sent to
tc-admin@oasis-open.org rather
than any one individual. (See Definitions: v.)
5. Remove language that was inadvertently left in the Process and
obsolete (references to Joint Committees and the need to notify the Chair
if you have signed up for a new TC but are unable to attend the first
meeting).
6. Leaves of Absence - proper procedure for submitting requests.
(See
Section
2.6)
7. Standing Rules - allowing for amendments and recisions, as well as
explicitly stating that they must be posted on the TC web page in order to
be enforceable. (See
Section
2.9)
8. Clarification with regard to what can and cannot be changed after
approval of a Committee Draft, Committee Specification, or OASIS Standard.
(See
Section
2.18)
9. Clarification of the Designated Cross References language.
(See
Section
2.19)
10. Clarification of the Appeals process. (See
Section
4.2)
If you have any questions please feel free to contact me.
Regards,
Mary
Mary P McRae
Director, Standards Development
Technical Committee Administrator
OASIS: Advancing open standards for the information society
twitter: fiberartisan #oasisopen
phone: 1.603.232.9090
Standards are like parachutes: they work best when they're
open.