OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Thoughts on comments received on CfC for "Best Current Practices" TC [BCP]

Dear convenors and all:Â

I hope to be able to join you for the BCP TC convener call later today. I read through the comments to your proposal, and in light of some raised objections, let me contribute a few questions and observations. (Two possibly-key questions for the convenors appear at the bottom of this note.) Â

Disclaimer: (a) These only are non-normative opinions from one OASIS staff member, with some experience in this field, but as suggestions, not as rulings by OASIS or its TC Administrator, who this decade is Chet not me. (b) This is not a member comment that requires logging or response under our rules. It's facilitative optional staff feedback, post-deadline, after reviewing the logged comments.
  1. Critiques of charters generally: We should be very hesitant to critique any OASIS TC proposals for reasons other than rule conformance. OASIS has distinguished itself for years as a forum where a sufficient number of supporters may launch a proposal, without risk of political or technical disagreements about its merit. That's a feature of OASIS, not a bug, Any objections to elements of this charter should be viewed primarily by whether they're permitted by our rules. That some proposed project may be thought redundant, or low priority, or has disputed technical or policy goals, normally never has been an actionable objection in our system.
  2. TCs about TCs: OASIS has hosted multiple TCs over 20 years whose scope is to create internal guidance or suggested practices for TCs and other standards projects -- such as the Conformance TC (1999-2002) and the TAMIE TC (2009-2017). So it seems clear that development of useful methods for running a TC is not generally out of scope for an OASIS TC.Â
  3. Which deliverables are really a problem? Reading this proposed charter and comments, I did not see as many collisions between OASIS official guidance, and these proposed deliverables, as some others. I'll send along a couple of examples of (in my opinion) clearly virtuous and useful proposed work products later. It looks to me like there's some good stuff in here, and I hope OASIS can find a way to support its goals.
  4. Still, OASIS can act to keep its rules clear. At the same time, though, this project's plans do relate to core interests of OASIS rulemaking. As several have suggested, I think OASIS does have some legitimate interest in asking for changes to charter content if it creates serious confusion or explicit rule collisions. Let me mention two specific possible problem areas. Â
  5. "Best practices". First, OASIS has almost always avoided the phrase "best practices" in its own outputs, because we didn't want either to incur the implied liability of that assertion, and (in light of the extreme breaths and diversity of OASIS dev communities) did the identification of any one method as "best" seems potentially misleading in many cases. So, to process this charter and its proposed name, OASIS may need to confirm whether the words "best practices" are in fact reserved by us, or prohibited by us, as a matter of policy. My question to you: is that name/claim a negotiable element of your proposal, or would OASIS need to place it on hold, if that determination requires formal action before approval?
  6. Handling any direct contradictions. Second, there are some concerns expressed that, without clear scope boundaries, there could be direct collisions between the TC's output and OASIS rules, creating confusion for implementers and members. By collision, I mean a case where the TC's finalized spec bearing the OASIS says normatively that standards developers should do X, directly contradicting an OASIS process rule or Instruction that today says that standards developer should do Not-X; or the spec asserts a normative requirement that OASIS does not today require. It's possible that those sorts of conflict could be avoided simply by including a few scope limitations in the charter. My question to you: How do the proposers wish to address rule collisions? Here are some examples for further thought (again, just opinions here):
  • TC work product that addresses existing OASIS process rules or guidance must be clearly labeled as either conforming to, or proposing changes to, rules currently in force.
  • Any proposals to change the OASIS process rules or guidance must be presented in a manner that does not give the appearance of OASIS approval, effective rule amendments, or an existing, enforced alternative or optional rule set.
  • OASIS TC Admin reserves the right to insert appropriate special captions within any TC work product, including its front matter, to make the foregoing distinctions clear.
Someone mentioned a concern with alignments with OASIS rules changing over time, as well. I can only note that all OASIS publications are timestamped. Very possibly, some of the 2001 Conformance TC publications have obsolete elements in 2019 ... but we don't require that they be updated or deleted. They're historical conclusions speaking as of the time of that publication.

Hope this helps. Opinions only. Cordially Jamie

James Bryce Clark, General Counsel, OASISÂ
Advancing open data, code and standards for the global information society https://www.oasis-open.org/staff

OpenMobilityFoundation.org (new), an OASIS-hosted open source program
EU 2019 Rolling Plan for ICT Standards: https://j.mp/EUstds2019


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]