[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: TAB Comment on ECF v5
|
Greetings! Members of the OASIS Technical Advisory Board (TAB) comment on public review drafts as part of their TAB activities. I have only one (1) comment but as a close friend in Swindon (UK) would say, it has several parts: My primary concern is the conformance clause which reads in full: ***** An implementation conforms with the Electronic Court Filing Version 5.0 if the implementation meets the requirements in Introduction, Service Model, Information Model, and Court Policy including conformance with the XSD schemas and [Genericode] code lists referenced in Information Model and Court Policy. ***** Comment Part 1: "requirements" As you point out in 1.2 Normative References, "requirements" in ECF v5 are defined by: ***** Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
http://www.rfc-editor.org/info/rfc2119. ***** which you cite at 1.1 Terminology saying: ***** The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
in this document are to be interpreted as described in [RFC2119]. ***** OK, but the key words define differing *levels* of conformance. That is “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” define requirements than a "conforming" implementation may choose to ignore or to use. My first point being that to say: ***** meets the requirements in Introduction, Service Model, Information Model, and Court Policy including conformance with the XSD schemas and [Genericode] code lists referenced in Information Model and Court Policy. ***** Isn't meaningful. What if my implementation takes the optional/may/should choices and another application doesn't. Are both of those conforming implementations of Electronic Court Filing Version 5.0? Comment Part 2: "requirements language" The key words: MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” appear in ECF v5.0 as follows: MUST - 144 (rough count, I didn't eyeball each one) MUST NOT - 11 times (including twice in Appendix F, which is informative) REQUIRED - 21 times but aside from 1.1, always in lowercase. Better to avoid its usage if you really mean MUST. SHALL - 1 Did you know there is an errant use of "SHALL" in 6.1.6
ServeProcess? Second paragraph, convert to MUST. SHALL NOT - not outside 1.1 SHOULD - outside 1.1 some 47 times (excluding should not) SHOULD NOT - 5 times outside 1.1, once in lowercase in 6.1.4 ReviewFiling. Did you mean upper case? RECOMMENDED - 2 times outside 1.1. Last paragraph of 2.1 (don't
use requirement terms in informative text), and 4.4 in the first
unnumbered example MAY - 87 times outside of 1.1, sometimes in lowercase, sometimes
in UPPERCASE. - MAY should always appear in UPPERCASE to avoid
confusing readers as to the requirement being expressed. From 1.1 key terms for example: Party A litigant in a case. A party may be a person, organization
or property (e.g. “in rem” property). OPTIONAL - outside 1.1 it appears 28 times, always lowercase: ***** The operations defined by ECF 5.0 to support this cycle are listed below. The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented. The other operations are optional and MAY occur within a given filing: ***** Replace optional, if you don't mean it as a requirements keyword with something else. The "permissive" requirement keywords appear a total of 169 times. Err, that means there are 169 variant implementations that can all claim conformance under: ***** An implementation conforms with the Electronic Court Filing Version 5.0 if the implementation meets the requirements in Introduction, Service Model, Information Model, and Court Policy including conformance with the XSD schemas and [Genericode] code lists referenced in Information Model and Court Policy. ***** That is at variance with the major design elements of 3.1, as it contemplates the *interchange* of information between processes. Multiple "conforming" implementations that cannot interoperate make a poor argument for a "standard."For example, what if my File Review MDE fails to support any optional elements for Filing Assembly MDE and does so by discarding any elements it chooses to not support. (You could in a conformance statement require that any File Review MDE *preserve* ECF v5.0 markup that is recognized but not used by the File Review MDE. (That's an example and not a suggestion of a conformance clause.) Meaningful conformance clauses would enable vendors to claim conformance to any of the MDE's in such a way that a concerned party could mix and match them based not only on vendor features but on what parts of ECF v5.0 they supported. As the conformance clause reads now, guesses for grabs on evaluating claims of conformance or their use by government procurement agencies in specifying desired software (another popular use of standards). Even with detailed conformance clauses, there is plenty of room for vendor features, but it provides a baseline of conformance that protects consumers of products based on those standards from being surprised to find that expensive "conforming" software doesn't work with other expensive "conforming" software. It may help to think of your modules, etc., as producers and
consumers of information so you can specify what a conforming
producer produces and what a conforming consumer must accept. I think you have done the heavy lifting on that issue but having
the components, you didn't specify their interaction with each
other sufficiently to have meaningful conformance. **** end of first comment**** Apologies, I have a second comment. All examples, figures and tables should be titled and numbered
for reference purposes. Creating the conformance clauses is a non-trivial exercise but it could help establish a defined market for modules that work together. Hope you are at the start of a great week! Patrick -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau |
Attachment:
signature.asc
Description: OpenPGP digital signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]