dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] FW: [members] Changes to OASIS TC Process Policy
- From: Eric Sirois <esirois@ca.ibm.com>
- To: "Ogden, Jeff" <jogden@ptc.com>
- Date: Tue, 11 Aug 2009 13:49:57 -0400
Hi Jeff,
There is one instance where the XSDs
can enforce what is defined in the spec where the DTDs cannot. That
instance deals with dates. The spec says that we must use ISO standard.
The XSDs can enforce that via one of its native datatypes.
Eric
Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA XML Schema Architect and DITA Open Toolkit Developer
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue
Pages (Internal)
"Transparency and accessibility requirements dictate that public information
and government
transactions avoid depending on technologies that imply or impose a specific
product or
platform on businesses or citizens" - EU on XML-based office document
formats.
From:
| "Ogden, Jeff" <jogden@ptc.com>
|
To:
| "Dana Spradley" <dana.spradley@oracle.com>,
<dita@lists.oasis-open.org>
|
Date:
| 08/11/2009 01:13 PM
|
Subject:
| RE: [dita] FW: [members] Changes to
OASIS TC Process Policy |
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:dana.spradley@oracle.com]
Sent: Tuesday, August 11, 2009 12:23 PM
To: dita@lists.oasis-open.org
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); dita@lists.oasis-open.org
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:bnevin@cisco.com]
Sent: Wednesday, August 05, 2009 2:20 PM
To: Dana Spradley; dita@lists.oasis-open.org
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:dana.spradley@oracle.com]
Sent: Wednesday, August 05, 2009 3:52 PM
To: dita@lists.oasis-open.org
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:mary.mcrae@oasis-open.org]
Sent: Wednesday, August 05, 2009 12:25 PM
To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
Cc: OASIS TAB; board-plus@lists.oasis-open.org; 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 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
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
twitter: fiberartisan #oasisopen
phone: 1.603.232.9090
Standards are like parachutes: they work best when they're
open.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]