[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: OASIS PAC meeting 2001.06.27
Forwarded on behalf of Jon. </karl> -----Original Message----- From: Jon Bosak [mailto:Jon.Bosak@sun.com] Sent: Wednesday, June 27, 2001 11:01 AM To: workprocess@lists.oasis-open.org Cc: btusdin@mulberrytech.com; dalapeyre@mulberrytech.com; eduardo.gutentag@sun.com; gkholman@cranesoftwrights.com; karl.best@oasis-open.org; lauren@softquad.com; robin@isogen.com Subject: OASIS PAC meeting 2001.06.27 (Sorry for the crude mailing; my mail domain just got changed, and the OASIS listserv no longer knows me.) As we decided previously, we will be meeting today from 11 a.m. to 1 p.m. California time to discuss the remaining issues on Karl's list (see below). dial-in number 517 267 0146 participant code 592285 Jon ================================================================== Standards Process ================= 11. Is OASIS justified in calling the results of our process a "standard", as we are not a de juere standards organization? __ agree that OASIS should call its work "standards" Lauren: Why not? As long as the adjective is there. Tommie: An organization becomes a standards organization first by saying it is, and then by other people accepting it. There is no "official" designator of standards organizations; if OASIS wants to be a standards organization then it needs to say so, and then act like it is. Debbie: What is a standards organization? W3C is not one, ISO is by international consent, but what about IETF, IEEE, AMS, et al. There are no "standards police". We are if we say we are and can back it up. The process takes both implementations and votes. Enough? Ken: the ISO defines a difference between standards and reports: a standard is something used by others, a report is something illustrating a standard; for example, ISO 8879 is the International Standard for SGML, while ISO 9573 is a technical report on the use of SGML at ISO Central Secretariat - there aren't many reports, but they are distinct from standards - I think we could have the same distinction in OASIS __ disagree that OASIS should call its work "standards" __ neutral that OASIS should call its work "standards" Robin: I'm not sure "justified" is the most relevant aspect of the question; "standard" is used in many ways, and I don't think anyone has the authority to declare what a "standard" is or is not. However, I am interested in the notions of relative stability/maturity and competence, as possibly communicated through the word "standard." I wish we had something like NISO has in "Draft Standard For Trial Use (DSFTU)" -- the notion that "we think this is a mature specification, but we won't know for a year or two, based upon long-term implementation reports." I rather think "standard" should be reserved for something that's proven to work, and question whether a company's mere saying "yeah, we implemented it" [no real feedback from users yet] is actually sufficient grounds for calling something a "standard" in the sense of being proven to work well. Note that the "NISO Circulation Interchange Protocol (NCIP)" as DSFTU is in limbo (extended Review Period) January 15, 2001 - January 15, 2002. __ I believe this warrants serious discussion Eduardo: I thought we'd talked this one to death, but obviously not. ---------------------------------------------------------------------------- 12. Define how existing/completed work can be submitted to OASIS to become an OASIS Standard without having to go through a TC. (I suggest that we simply require three PEOTCPs to submit the work and certify three implementations on the existing quarterly schedule. This would save the effort of setting up a TC and the 45 days wait to hold the first TC meeting.) __ agree with suggestion __ disagree that we should allow this Robin: I can't quite see the urgency (less than 45 days). What political force (beyond mere utilitarian value?) is gained by hasty/immediate adoption of an existing standard as an OASIS standard? Debbie: Standard process, why the hurry? Ken: my perception is that there have been only problems at ISO/IEC JTC 1 with the PAS submission process ("Public Available Specification") and the actions of qualified PAS Submitters (groups deemed to have sufficient public input to qualify publicly available specifications as having been an open and fair development) - to avoid problems I think anyone wishing to take existing work in to OASIS go through all the regular channels to ensure appropriate involvement __ I believe this warrants serious discussion My alternate suggestion: Eduardo: I think that existing/completed work should be submitted to the Oasis Board as if it was coming from a TC, and take it from there (that is, submit it to Membership vote, etc.) ---------------------------------------------------------------------------- 13. Should we do anything different for committee work that is not designed to be submitted to membership for creation as an OASIS Standard? (e.g. conformance test suites are considered tools, not specs, so are not submitted to become OASIS Standards.) Should the committee work product still be reviewed by membership? __ agree that committee work should be reviewed by members Lauren Robin: People change their minds. __ disagree that committee work should be reviewed by members Ken: when was it decided a test suite wouldn't be an OASIS standard? I think it qualifies ... it is something that is used by others, not just illustrative - one of the benefits of the process was that it was available to members to be used as a tool to come to some kind of closure of their own definition ... I don't see membership review as being required __ neutral that committee work should be reviewed by members __ I believe this warrants serious discussion Eduardo: I think that test suites should be considered specs, not tools. Don't see why they can't be submitted to vote. Tommie: Where did the distinction between "tools" and "specs" come from? And since when is a test suite not a specification? It's a specification for conformance, and I don't see that it's any different from any other specification. Debbie: Disagree wholeheartedly. Either this question shows a misunderstanding of the entire process or I do not completely comprehend the question. TC does NOT = standard; a standard is one possible result of the process. But the converse is also true, there no committee work that "by definition" is never destined to be a standard. The process is separated into many phases for just this reason. At the end of each phase, a TC chooses whether or not to move closer toward "standardness". LOTS of TCs may never produce standards, because that is not their goal, or they don't need to, or they don't think their work was good enough, or technology overtook them, or lots of reasons. Remember, a TC could CHOOSE not to try to make a standard. But I am not at all sure that you can know, for certain and all, *when the process starts* where it will wind up. A nothing of an idea may sprout into a standard and a ripe, good idea may run afoul of any number of things. I maintain that you cannot reliably identify this category of committee work. Should the committee work product still be reviewed by membership? __ agree that committee work should be reviewed by members __ disagree that committee work should be reviewed by members __ neutral that committee work should be reviewed by members None of the above. ONLY if the committee asks, should the membership review. If a TC asks, then, yes it should. After all a report out of committee is just that and needs no membership approval or oversite. Aside: Why isn't a test suite just the same as any other "standard"? I feel this is an artificial distinction. ---------------------------------------------------------------------------- 14. Add that member organizations voting on a proposed OASIS spec must be members at the time the proposal is submitted to the membership, i.e. the start of the evaluation period. The 10% required for voting should be based on the number of member organizations at the start of the evaluation period. This is to prevent the vote from getting invalidated if we get a bunch of new members during a ballot period. __ agree to base vote on membership at start of evaluation period Eduardo; no need to discuss Lauren Tommie Debbie Ken __ disagree to base vote on membership at start of evaluation period __ neutral to base vote on membership at start of evaluation period Robin __ I believe this warrants serious discussion ---------------------------------------------------------------------------- 15. Add to the checklist that the committee’s submission (for a TC specification to be voted on as an OASIS standard) must include a statement regarding IPR compliance. Also, the submitted committee specification doc must include the OASIS copyright statement that is in the IPR. __ agree to add IPR and copyright to checklist Lauren Robin Ken __ disagree to add IPR and copyright to checklist Tommie: We discussed this at length, and decided that since there was already an OASIS IPR policy anything we added would simply muddy the waters. If there are two rules about the same thing there can be conflict about which applies; if there is only one rule (the current OASIS IPR policy) then it clearly applies. It might be appropriate to note in the non-normative manual for committee chairs that there is an IPR policy. Debbie __ neutral to add IPR and copyright to checklist __ I believe this warrants serious discussion Eduardo: Sorry, this confuses the hell out of me. Doesn't including the Oasis copyright moot all other IPR issues? ---------------------------------------------------------------------------- General/Other ============= 16. In section 9 the mail list requirements aren’t very workable: there are two lists (discuss and comment) used to satisfy three groups of people (TC members, OASIS members, and the public). The comment lists are required to exist but are unused. I suggest that the TC process should simply describe the effect (e.g. "allow outsiders to post comments to the discussion list") without describing the method to accomplish the goal; let the list administrator figure out how best to do it. For example, the discussion list could simply be opened to postings from the public; subscriptions would still be restricted to members. This would do away with the need for a separate comment list. __ agree with suggestion __ disagree with suggestion Ken: while I acknowledge it isn't being used well yet, I think the distinction is important; as I understand it the committee is not obliged (but may do so if they choose) to respond to any post or statement made to the comments list; by having it separate this division of responsibility is kept clear __ I believe this warrants serious discussion My alternate suggestion: Eduardo: same comments as #10 Lauren: The ER TC list does use the comments list and we find it useful. Maybe the problem is that people aren't yet used to the new process, and most TCs aren't far enough along yet to use the comments lists? Tommie: I don't mind if the requirement is stated functionally, but this suggestion ignores one of the key functions of the dual list system. (The argument that something people don't know about isn't needed because it isn't used is specious). I think it would be very valuable for TC members to be able to separate (by use of an email filter) mail from TC members and mail from the outside about the TC. This will be especially important if OASIS has any controversial TCs; without the ability to do this filtering vociferous non-members could flood the TC list, making TC work on a list virtually impossible. Robin: Need discussion of the exact problem here... Debbie: Discuss. I really liked the idea of separate. ---------------------------------------------------------------------------- 17. I suggest a shorter amount of time to kill an inactive TC. Currently in section 11 an inactive TC can only be killed at the beginning of the year after a full year without a meeting; this could be 12-24 months of inactivity before the TC can be killed. I suggest that six to nine months of inactivity (no meetings, no substantive discussion) would be better. It’s publicly embarrassing to OASIS to have to publicize inactive TCs, and extra effort is required for OASIS to maintain the TC on our lists, etc. __ agree with suggestion Ken __ disagree with suggestion Tommie: Why is it embarrassing to say that there are groups working at various speeds? And that some are available if needed but not currently active? Robin Debbie __ I believe this warrants serious discussion My alternate suggestion: Eduardo: Sustaining TC may not have reason to meet often. This does not constitute a reason to kill them. I think there should be a provision for a TC's chair to declare a TC inactive or terminated, thus permitting its removal forthwith. Lauren: Why is it embarrassing to OASIS when member initiatives aren't well attended? You just say "they're member initiatives". ---------------------------------------------------------------------------- 18. The TC Process does not define how to set up subcommittees of the TC, and doesn’t say anything about them at all other than mentioning them as part of the Joint Committee discussion. The Process should provide guidelines/rules for their creation and operation. __ agree that process should define subcomittees __ disagree that process should define subcomittees Eduardo Tommie: There should be a lot of variation at this point; large TCs will want more subcommittees than small, and more structured subcommittees. Since from the point of view of Roberts subcommittees are ephemeral I don't see why we would need to be prescriptive in this area. Debbie: Is it dangerous not to set up a process? In what way? Please prove need. Ken __ neutral that process should define subcomittees Lauren Robin: What rules/guidelines/instructions need to be defined? I might agree if there's a demonstrated need. __ I believe this warrants serious discussion ---------------------------------------------------------------------------- 19. The TC Process says little or nothing about how a TC operates once it has been set up, other than specifying RRO for the conducting of business. Should more be specified? or is a non-normative guidelines document sufficient? __ agree that more should be specified __ disagree that more should be specified Lauren Tommie: The guidelines should be sufficient, and suggestive only. If we tie this down too tightly we'll kill it. Robin: What "more" would need to be said? Debbie: Non-normative guidelines only! Ken __ neutral that more should be specified __ I believe this warrants serious discussion Eduardo: A non-normative guidelines document should be sufficient. ---------------------------------------------------------------------------- 20. I suggest that throughout the process document we drop the acronym "PEOTCP" and simply use the phrase "eligible person" instead. This would make the process document easier to read. __ agree to replace "PEOTCP" with "eligible person" Robin: If not "eligible person", something similar... __ disagree to replace "PEOTCP" with "eligible person" Eduardo: What I object is a global s/PEOTCP/eligible person/ I think some thinking should be applied, as there may be some places where PEOTCP is needed rather than "eligible person". Lauren Tommie: "eligible person" would have to be very carefully defined, and might be confused with people eligible for something else. PEOTCP is ugly, but it is clear. Debbie: "eligible person" would need defining. The beauty of an ugly non-standard term is that it must be looked up, since no one will know it, and is easy to remember and identity, once learned. Ken __ neutral to replace "PEOTCP" with "eligible person" __ I believe this warrants serious discussion
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC