Dana,
You had me confused there for a bit. #3 in
Mary's message says:
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)
Reference is
to:
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.
As you say, "the DTD we supply in separate plain-text files [is] normative, and
... override[s] whatever we actually say in the specification itself".
But this overriding happens only if we screw up and don't implement what we say
we specified. Another way to paraphrase is to say that delivered bugs
prevail over specified intentions.
The paragraph that you quoted
was evidently not changed in this revision. It is:
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).
Since this paragraph is not
singled out as a revision in Mary's message, it seems that we were already
supposed to have a section that summarizes what "DITA conforming" means. My read
is that this doesn't have to be a quotation of each and every normative
statement in the spec, so long as the numbered conformance clauses taken
together cover the same ground.
/Bruce
From: Dana Spradley
[mailto:]
Sent: Wednesday, August 05, 2009
3:52 PM
To:
Subject: [dita] FW:
[members] Changes to OASIS TC Process Policy
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
-----Original Message-----
From: Mary McRae
[mailto:]
Sent: Wednesday, August 05, 2009
12:25 PM
To: ;
Cc: OASIS TAB;
; OASIS Staff
Subject: [members]
Changes to OASIS TC Process Policy
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 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
email:
web: www.oasis-open.org
twitter: fiberartisan #oasisopen
phone: 1.603.232.9090
Standards are like parachutes: they work best when they're
open.
