[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] FYI regarding resolution to CSD and PR requests for EMIXversion 1.0
Thank you Chet, for helping us to work through this vexing and more complicated than it appeared issue. tc "It is the theory that decides what can be observed." - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com -----Original Message----- From: Chet Ensign [mailto:chet.ensign@oasis-open.org] Sent: Thursday, July 07, 2011 8:28 PM To: William Cox; Toby Considine; emix@lists.oasis-open.org; OASIS Board Process Committee; Laurent Liscia Cc: Jamie Clark; Scott McGrath; Robin Cover; Paul Knight Subject: [emix] FYI regarding resolution to CSD and PR requests for EMIX version 1.0 Summary The Energy Market Information Exchange (EMIX) committee specification draft 03 has been created and prepared for a 15 day public review. However, as currently loaded in the OASIS Library, the EMIX schemas do not validate because references to the WS-Calendar schemas are broken. After much email, conversation and consultation, I am approving a resolution to this problem that, upon reflection (see below), does not conform to the TC Process, specifically section 2.19, Designated Cross Reference Changes. I am taking this action because: (a) I failed to provide direction to the TC when specific guidance was requested, (b) in the absence of that guidance, the TC endeavored to take what it believed to be appropriate corrective action and (c ) the resolution that does stay within the bounds of the TC Process establishes a precedent in the OASIS Library that I believe to be more undesirable than this one-time action. This action does not establish a precedent for future TC Administration action because it is solely due to these unique and isolated circumstances. In particular, it does not affect the Energy Interop committee specification request that has just been made and where the same basic issue must be resolved. I will work separately with the Technical Committee to appropriately fix that submission to be within the bounds of the TC Process rules. Resolving this issue has also raised questions about the interpretation and application of section 2.19 of the TC Process. I will take up these questions with the Board Process Committee and, if a gap in our process is identified, work with them to try and close it. Background Facts On June 22nd, the TC editor sent an email to the tc-admin email address noting that the TC was preparing a work product using copies of the WS-Calendar schemas because the WS-Calendar schemas had not yet been published to the OASIS Library and asking, "If we vote EMIX out of committee tomorrow, how do we handle this problem, which I would fix now if I could, but whose proper resolution is dependent upon the TCAdmin work schedule?" (The EMIX schemas reference the WS-Calendar schemas.) I did not provide an answer to his question. On June 23, a request to create Committee Specification Draft 3 (CSD03) of Energy Market Information Exchange (EMIX) specification and to submit the draft for a 15 day public review was made to TC Administration (TC Administration tickets TCADMIN-556 and -557). The zip file with the specification approved by the TC included copies of the schema files for WS-Calendar. The TC's submission ticket included a request that "the TC Administrator insert the correct Public URIs for WS-Calendar CSD04/PR03 [not yet released as of this request] as they process wd35 specification and schemas for publication as EMIX CSD03." I did not respond to the TC's request. On June 29, while working on CSD03, TC Admin deleted the sub-directory containing the WS-Calendar schemas from the CSD directory structure however TC Admin did not replace the EMIX xsd's that referenced those copies with replacement xsd's provided by the editor that pointed to the official WS-Calendar schemas. As a result, TC Admin produced a CSD with schemas that did not validate. On July 6, the TC was notified that CSD03 was loaded and asked to spot-check them. The editor quickly notified TC-Admin that the schemas were invalid and urgently asked that we fix them, either by replacing the sub-directory with the copies of WS-Calendar schemas or by replacing the EMIX schemas with provided copies that referenced the canonical copies. We have had numerous back and forth emails and phone calls today on fixing this problem. Analysis & Resolution: Clearly, the broken schemas must be fixed before EMIX is released to public review. Three options are available: - Replace the sub-directory containing copies of the WS-Calendar schemas in the EMIX xsd sub-directory, or - Edit the EMIX schemas to point to the current versions of the WS-Calendar schemas in the OASIS Library, or - Replace the EMIX schemas currently in the CSD with the copies supplied by the TC editor that point to the current versions of the WS-Calendar schemas Each of these comes with its own attendant pros and cons that must be weighed in making a decision: The first option stays within the bounds of the TC Process because we revert to the form of the work product submitted to us by the TC. However, it introduces a work-around that at a minimum clutters the OASIS Library with redundant copies of work-in-progress schemas and at worst could create confusion about what is the authoritative version of the schema or, worse, dependencies when developers implement code pointing to these unofficial versions of the schemas. I believe we want to avoid creating "facts-on-the-ground" like this simply to stay within the letter of the law. The second option flies in the face of the rule that TC Administration does not touch the actual content of specifications beyond a very limited number of changes specifically listed in the TC Process. This is critical to ensuring the integrity of the OASIS process and certifying that that contents of a specification are the approved work product of the Technical Committee and no one else. The third option violates the letter of the TC Process by replacing one part of a work product with another. The TC Process is abundantly clear on this point. In section 2.18 Work product Quality, sub-section 5 Multi-Part Work Products, it states: "Irrespective of the number and status of the constituent parts, the Work Product as a whole must be approved by a single Work Product Ballot" and in sub-section 6 Allowed Changes, it states: "Any change made to a Work Product requires a new version or revision number." It is clear that approving a multi-part work product, submitting it to TC Administration for official publication and action and then sending TC Admin subsequent requests to replace this part of it or that violates the intent of the TC Process rules. Indeed, to allow such piece-meal changes threatens the integrity of the OASIS process and jeopardizes the standing of our specifications in the larger technical community. However, in this situation, making such substitution appears to carry the least negative and the most positive consequences. It avoids the work-around sub-directory mess, it keeps TC Admin's keystrokes out of the TC's content, and it corrects the EMIX schemas so that they reference the canonical WS-Calendar schemas. It is in keeping with the intent of the TC as expressed in the approval minutes and it produces a higher quality specification by ensuring that the proper WS-Calendar schemas are referenced. Therefore, I am asking the TC Admin team to replace the existing EMIX schemas currently in the first CSD upload with the EMIX schemas provided by the TC editor that point to the correct WS-Calendar schemas. At the end of the day, we want our TC's to succeed at producing products that gain traction in their markets, recognition in their industries, and personal satisfaction to the people who put in the hard work to make them happen. Doing this means both helping them to deliver the highest quality specifications to their audiences *and* protecting the integrity and the reputation of the OASIS Process. OASIS' reputation is a critical factor to the TC's success because it assures adopters that our specifications are reliable and the result of an honest, open process. With this in mind, I've not taken this decision lightly but rather have done so in the belief that it is the best resolution for meeting the goals outlined above. Please let me know if you have any questions or comments. -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]