I agree with Kelvin that this is a problem. In some cases the
XML schema description cannot represent the rules specified in the text of a
specification. In such cases there is an inherent discrepancy because the
schema and the specification do not state the same thing. To say that the
schema file is correct would be technically inaccurate. As well, XSDs cannot
fully represent the RFC 2119 concepts. I fear this will lead TCs to not
include schema files.
From: Kelvin Lawrence
[mailto:klawrenc@us.ibm.com]
Sent: Friday, August 07, 2009 8:28 PM
To: Mary McRae
Cc: chairs@lists.oasis-open.org
Subject: [chairs] New rule on which document wins when there is
ambiguity
Fellow chairs,
I am way less
than 100% comfortable with the new rule #3 (documented at [1]) stating that
when there is a discrepancy between a normative specification and an external
document (such as a schema/xsd file) that the external document shall always be
assumed to be the correct one. I can think of several cases in the TCs that I
have either chaired or been involved with that this has happened and in every
case the spec was right and the external document was wrong. I would like to
understand why OASIS felt compelled to *mandate* this process, I would have
much preferred having the TC process require each TC to unambiguously state, in
the event of a discrepancy, which document should be assumed to be correct.
Am I alone in
this concern or do others of you share my view?
[1] http://lists.oasis-open.org/archives/members/200908/msg00000.html
Cheers
Kelvin (WS-SX co-Chair)
Kelvin R. Lawrence
Distinguished Engineer & CTO, Emerging Internet Software Standards
Member of the IBM Academy of Technology (http://www.ibm.com/ibm/academy)
IBM Software Group. 11500 Burnet Road, Austin, TX 78758.
e-mail: klawrenc@us.ibm.com Twitter: @gfxman
BLOG: http://www.ibm.com/developerworks/blogs/page/KRL