Sometime ago now we had a discussion about what to do when the
DITA spec. called for or allowed for something that could not be implemented or
enforced in a DTD, but could be implemented or enforced in an XSD. As I
remember it, the decision was that in such a case the language spec. was normative
and that the XSD would be considered normative over the DTD or at least the XSD
would not be considered as in conflict with the DTD in such cases.
First, am I remembering this correctly?
Second, if my memory is in fact correct, how does the OASIS rule
that the DTDs and XSDs are always normative over the specification?
-Jeff
From: Dana Spradley
[mailto:]
Sent: Tuesday, August 11, 2009 12:23 PM
To:
Subject: RE: [dita] FW: [members] Changes to OASIS TC Process Policy
Oh, and a DTD or schema being "normative" in this sense
doesn't mean that a conforming implementation must reproduce it verbatim - but
only that the specification it conveys through its own language conventions is
normative.
That is, a DTD or schema written somewhat differently, but that
enforces exactly the same element and attribute names, content models,
datatypes, etc as the delivered one does, would conform.
-----Original Message-----
From: Dana Spradley
Sent: Tuesday, August 11, 2009 9:09 AM
To: Bruce Nevin (bnevin);
Subject: RE: [dita] FW: [members] Changes to OASIS TC Process Policy
Hi Bruce--
Re: DTDs, schemas, and delivered bugs overriding specified
intentions: that makes a lot of sense. So I think we can't really just say the
DTD is normative, and the schema isn't, right? Each would be normative in their
own way - DTD for DTD implementations, schema for schema ones - and either
would prevail over the spec, until we correct the divergence.
And thanks for pointing out that the separate numbered conformance
clause section isn't new. I guess we should have done this before. And I agree
- so long as it covers the same ground, I suppose it doesn't need to reproduce
every single clause from the body of the spec.
But that probably would be safest...
--Dana
-----Original Message-----
From: Bruce Nevin (bnevin) [mailto:]
Sent: Wednesday, August 05, 2009 2:20 PM
To: Dana Spradley;
Subject: RE: [dita] FW: [members] Changes to OASIS TC Process Policy
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.
