page 263. you still have a reference to "CommunicationsLink" which is no longer anywhere else in spec.
Further, the properties defined here:
"1. capacity : String[] Details how much information can be passed on the Communications Link.
2. infrastructureTechnology : String[] Details the technology to be used to provide the communications infrastructure. "
should be defined for ResourceConnector instead.

In Section 7.3.2 of the Specification 2b-SysML_v1_to_v2_Transformation, there is no SysML v1 Library for SysML v2. I would like to have access to this library to play around with it since it is used for a lot of elements.

1) Duration constraint in table 20 says it maps to constraint definition but later says it is not mapped yet.

2) Time constraint in table 20 maps to constraint definition but table 21 says otherwise

3) 7.7.6.2.1 says Abstraction relationship is mapped to a sysml v2 dependency but the table 9 (7.7.6.1) says it is mapped to AllocationDefinition and SatisfyRequirementUsage.

4) 7.7.6.1 Comment in the table 9 is mapped to a v2 package but in 7.7.6.2.2 is mapped to v2 comment.

5) Constraint in table 9 should ALSO be mapped to a AssertContstraintUsage per 7.7.6.2.5

6) 7.7.4.2.27 - ParameterSet does have a mapping but the table 5 (7.7.4.1) indicates that it doesn't have a mapping.

7)7.7.4.1 - Instance Specification in table 5 is mapped to a connection usage. The actual mapping should be part usage. Linked instance specification should be mapped to connection usage. Should Add table row for Link Instance Specification

The P&P is rife with legacy terminology, but one of the more confusing bits is the use of the word 'beta' for the production of specifications.

In software development and in industry, 'semantic versioning' is a well understood de facto standard. It provides a well-formed and consistent format for conveying compatibility with prior versions of a product while clearly communicating lineage on a timeline.

The SemVer project documents this format with copious explanation, and is the most commonly used semantic version specifcation: https://semver.org

This highlights some of the current problems.

1. 'Alpha' and 'beta' have specific meanings in industry: an alpha version is incomplete and still being developed, while beta is used to indicate a product that has nominally finished its internal development, and is ready for public testing and feedback. This does not match the P&P definitions or guidance text in Sec 4.4.2, where Alpha is a document not yet worked on by an FTF, and Beta is an incomplete document during FTF and RTF, but Beta 1, Beta 2, etc are only products described in reference to an FTF, not an RTF.

2. There is disagreement on what the version of a Submission is (if any!) during the TC and BoD Adoption votes before it reaches its first FTF. (Section 4.1.2)

3. There is a broad misunderstanding that there are only Beta 1 and Beta 2 documents, which not only exposes a conflict within the P&P but is also not in line with industry norms. (See ABPSC-70 / ABPSC-71 for an example of a need for specific clarification on this point just to make sure a subgroup is following the P&P for a specification approaching the end of an FTF.)

Historically, the intent of the process currently documented in the P&P is close to current convention, but it is sufficiently out of step that it causes confusion.

Proposal: Adopt the SemVer standard for our versioning, throughout our process.

This complements the process in the P&P and would provide opportunities for clarification.

Any document that is being worked on by a TF, FTF or RTF that is not yet ready for public review is an Alpha. There can be any number of Alpha documents during a development, finalization or revision process. (This is a refinement of the Alpha Specification definition in the P&P.)

Any non-completed document that is available for public review and comment is a Beta. There can be any number of Beta documents produced during a review phase. (This is a refinement of the Beta Specification definition in the P&P.)

Any document that is being recommended for adoption (i.e. passing AB review, TC voting, BoD voting) is a Final Candidate. There can be any number of FC documents, but revisions will cause a restart of the recommendation process. (This is a new class of document not defined in the P&P.)

Any document that is formally adopted by the OMG as a final version of a specification will be a simple SemVer compliant x.y.z version. (This is a refinement of the Formal Specification definition in the P&P.)

A concrete example needs to be worked through in the Comments below.

This would greatly clarify where in the process a document is by quickly looking at the version, and also match widely adopted and understood versioning protocols. Unfortunately it would require a rather pervasive change to the P&P, but referring to SemVer 2.0 as the base would greatly simplify the language in the P&P and allow the specifics of the process to be more clearly communicated.

Currently a subgroup either exists, or is disbanded.

There may be utility in placing a subgroup into a 'hibernation' mode, where it is still technically operational, but recognized as inactive.

The Chair of an inactive (hibernating) subgroup reverts to the Chair of the relevant TC. (By default the TC chairs are occupied by the Technical Director.)

It appears 9 times, excluding in change notes. Let's add one more occurrence of the latter by removing all occurrences of the former.
No excuse for even keeping it as an option.

We should while we're at it review when a scanned signature is really necessary. Especially where it will appear in a posted document, due to the risk of it being copied and used fraudulently. There are many cases where we should be able to rely on the signer having an OMG login and, if we had an appropriate form, would give us as much reliability as needed. For example AB nominations, VtV requests, MC charters, proxies. After all, for many important votes, such as adoptions, an email vote is sufficient.
Others might need an alternative where the signer MAY not have a login: LOI, AB 25%.

The provision for proxy votes for F/RTF members is implied in the P&P but not explicitly stated.

All mentions of proxy voting provisions in the P&P in Section 3 are specific to one kind of voting body (TC in 3.5.1, 2 and 3; AB in 3.5.4; sub-groups in 3.7). In the case of sub-groups polls in 3.7 these explicitly exclude voting provisions for F/RTFs, with 3.7.3 stating that these are fully defined in Section 4.4.1.3. which makes no explicit provision for proxy voting.

Section 4.4.1.3 paragraph 1 states (in part) “Only F/RTF members may vote”. Paragraph 7 (counting bullets as a paragraph but not counting guidance notes), states;

“A Representative on the F/RTF who fails to vote in a contiguous sequence of at least two polls that complete during a period of at least two weeks is automatically removed from the F/RTF. A proxy vote or a vote of abstain is considered a vote for this purpose.”

This implies that proxy voting is supported but this is nowhere described in Section 4.

The accepted practice at the OMG is that we have allowed it in the past and that the named voting representative needs to name a proxy via the mailing list to make it official. However this may not have been implemented in the Jira system.

The P&P in Clause: 4.4.1.6 para 2 states:
“Any interim versions of the Specification published by the F/RTF during its life, and the revised Specification delivered with the report, shall be labelled as Beta Specifications, with a sequence number if required.”

This describes the need for Beta specifications to have sequence numbers if required but is non specific about the numbering. In practice we have adopted a tradition of having Beta1 as the baseline for FTF, Beta2 as the outcome of FTF and if needed the baseline for FTF2, and Beta3 as outcome of FTF2.

In order to provide clarity on how to characterize intermediate Beta versions, for example for the “before” and “after” versions of a generated specification for change markup, we recently introduce guidance to xTFs to use the intermediate designations Beta1.1, Beta 1.2 or Beta 2.1, Beta 2.2 etc. as appropriate.

There is no need to change the formal requirement in 4.4.1.6 but there is a Guidance Note at Clause 4.4.2 which is more specific and assumes that interim Beta will be numbered with whole numbers, which we do not do, and so is misleading. This Guidance Note can be updated to refer to the Beta 1.n, Beta 2.n etc. recommendation. It may also be expanded to describe the now-universal practice of having the specific roles for Beta 1, Beta2 and Beta 3 described above, which members may already assume is a requirement.

This change would make no change to the normative content of the P&P but bring the bracketed guidance notes into line with what we actually do and are proposing to do going forward.

I believe that the section heading:

6.1 Changes to adapted OMG Specifications [optional]

should be:

6.1 Changes to adopted OMG Specifications [optional]

https://doc.omg.org/ipr states:

once the RFP or RFC is issued, the IPR Mode for that OMG Specification may not be changed.

Unless we want to remind people about it or need it documented again for legal reasons, we should stop asking for it in AB Review and xTF Charter.

Some FTFs and RTFs maintain specification content in a textual format with changes managed in a version control system (GitHub). Example source formats include Markdown and LaTeX.

Identify whether any P&P changes are needed to support this. In addition, provide detailed procedural documentation and guidance specific to this scenario.

Note that while current practice is to record all change proposals as manual editor instructions, the P&P calls only for textual change information.

Need detailed procedure for how to satisfy the following two process requirements, for specifications or specification content that originates from a model rather than as written text.

1. What xTF members view when they vote on a proposed change
2. What the xTF Report Convenience Document (change bars) presents in order to show each change since the prior version, each annotated with the Jira for the change.

Splitting the finalization process into FTF and FTF-2 (as separate taskforces) is highly counter-productive. In many FTFs, JIRA and other electronic tools are used to organize, control, and facilitate the finalization process. This includes interactive discussions and design work to reach the best solution in collaborative work of the FTF members. Splitting this continuous work arbitrarily into two logistically separate task forces at the 14 months mark is damaging for the efficiency of this process. It would be much favorable to have ONE FTF, with constant membership and constant work environment throughout the whole finalization process. A checkpoint and intermediate reporting shall be introduced after 14 months, and the extension to 24 months shall be dependent on AB endorsement of the checkpoint report, and TC vote.
This scheme preserves the timing idea of FTF/FTF-2, but preserves the continuous work environment for the FTF.

The OMG working language is British and Commonwealth English, as this is the required language for ISO specifications. For consistency we have carried this language policy through to the RFP, which does not go through the ISO PAS process. Meanwhile not all RFC are expected to go through ISO.

At present, our RFP Template uses the alternative British endings of 'ise'. whereas ISO requires that also-British 'ize' endings on certain (not not all) kinds of words that take 'ize' in the US.

The P&P does not formally require an LOI for RFCs, although we proceed as though it does. Instead the P&P gives a list of things that should accompany an RFC submission, and our RFC LOI Template satisfies those requirements.

The list is vaguer than the LOI, particularly for the requirement to grant OMG a perpetual, nonexclusive, royalty-free, paid up, worldwide license to copy and distribute.

The recently revised Revision Report Administration Page provides a number of good improvements, but it is still very unintuitive, and compared to the previous version, fails to satisfy the community and process needs.

Clear and understandable input fields are required for the following information. Each input filed must have a clear and specific title, leaving no question about purpose and format:

(1) Specification Information:
(1a) Exact Specification Title
(1b) Specification Version [ no "Alpha", "Beta", etc ]
(1c) Specification Acronym
(1d) Specification Version Stamp

Document Information Note, there may be multi-volume specifications. The input format must support that.

(2) Specification Document Input (for each specification volume):
(2a) Exact name of the Specification Volume [ with implied document number assignment ]

Alternatively, input of a multi-volume specification as ZIP archive shall be supported:

(2b) ZIP Archive Name [ with implied document number assignment ]
(2c) File Name and Exact Volume Title for each specification volume [ repeated ]

Note, in a multi-document specification, not every document may have changed during the revision process, therefore it would be very helpful for the specification reviewer if the changed documents could be flagged.

The exact same facilities as under (2) must be provided for change marked specification volumes.

The creation of ancillary attachment files / archives for the purpose of the revision report shall be transparent and invisible to the user

Machine Consumable Files:

All Machine Consumable Files MUST have a Version Stamp URL. This is necessary for version management, until the OMG adopts a professional version management scheme, like GIT, etc. For files that require a different (additional) URL, an optional URL filed shall be provided by the input facility. Single File Input and ZIP Archive Input shall be supported. The below described Input Facility shall be provided two times with identical layout. Once for NORMATIVE files, and once for INFORMATIVE files.

(3) Machine Consumable Files Input
(3a) File Name [ with implied document number allocation ]
(3b) File Description
(3c) Alternative URL [ optional ]
(3d) Version Stamp Override [ optional - accommodating reuse of files from previous versions ]

For Multi-File Input as ZIP Archive:
(3e) ZIP Archive Name [ with implied document number allocation ]
Then repeated input (3a) to (3d) for each file in the ZIP Archive.

As stated, this input facility must exist twice with identical layout, for NORMATIVE and INFORMATIVE Machine Consumable Files.

Specification Maintenance Support.
To facilitate specification maintenance, a specification maintenance archive is required. It is currently called "Ancillary" but shall be called "Maintenance" to avoid confusion with the ancillary attachments of the report.

The Maintenance Archive shall have a private URL with the SAME Acronym and Version Stamp as the corresponding Normative Machine Consumable Files of the Specification to allow unambiguous association.

Only the Maintenance Archive file name [ with implied document number allocation ] is needed as input field.

However, the Maintenance Archive must contain at least:
(4a) SVG files for all images
(4b) Editable Model sources - if models are used in specification
(4c) Document sources - if needed for reproduction
(4e) Other necessary items

There is a conceptual confusion about "Ancillary":

(a) The report generates an “ancillary archive” which contains all the attachment stuff from the JIRA process.

(b) The Taskforce Chair is required to provide Maintenance Material, which are SVG images, Models, Document Sources, etc., and that is also called an “ancillary archive”

The report administration page apparently does not understand this distinction. Also, to resolve this confusion and double-usage of “ancillary”, I strongly recommend the introduction of category “Maintenance”, reserved for specification maintenance material, replacing that usage of “ancillary” and be as private as all the ancillary files before.

In addition, Specification Maintenance Archives must have the Version Stamp in their file name (or otherwise associated with the file), so that the particular maintenance archive can be unambiguously associated with the corresponding specification version. Since at least the model inside the maintenance archive is directly associated with machine readable files, the Version Stamp is preferred over the Specification Version.

Documents within specifications are explicitly categorized as "Normative", "Informative", etc. This categorization is used within the Jira system, and is generally accepted by membership.

There is no document within the OMG that defines this set of categories or describes when they are appropriate.

This is not only in the list of references in B.1 but in section 2
For example the following, while not formally retired, are not mentioned or reused in any meaningful way:

• section 2 lists mappings in EDOC and to COM. And conversely does not list far more widely used mappings e.g for GraphQL, JSON, REST.
• section 2 again lists dated services such as Naming Service and Trading Object Service
• section 2 lists OMA which I think is pretty irrelevant
  In summary, I think a knowledgeable team of MARS and other experts should clean it up and use more recent and relevant examples.

View specification for <<Standards>> elements do not allow for directed composition into other <<Standards>>. Specification for <<Standards>> elements do not specify a part property.
This is needed because many ConformsTo relationships conform to only a specific part of a standard, rather than the entire standard. Traceability is enhanced by allowing for a UAF Element to ConformTo a standard at a lower level than the parent.

Current Jira template is not optimized for Diversity and Inclusion issues.

Consider changing Jira to support this better. Possibly via an issue type, custom field, or label field.

For now, I am labeling this with a 'D&I' label.

Section 4.1 of the Hitchhiker's Guide, V7.8 includes this:

A typical Task Force voting scenario is as follows:
1. The Task Force meets at least once to discuss the RFP prior to any Architecture Board (AB) review. By policy, a RFP cannot be issued at the same meeting that it is first discussed.
2. A spokesperson(s) presents the RFP to the AB at its first meeting day (by convention, Monday afternoon) for initial review.
3. The AB may or may not request minor revisions.
4. The RFP working group makes necessary changes (if required).
5. AB and subsequent Task Force changes (if any) are reviewed and the vote to recommend issuance occurs in a Task Force meeting prior to the AB’s second meeting day (by convention, Thursday afternoon).
6. The (modified) RFP is presented to the AB at its Thursday meeting with a request to vote its recommendation for issuance.

I think item 1 needs to be added to the P&P to ensure it's not just a de facto policy – which, unless it's in the P&P – is all it is. I don't know where (Section 4.2.1?) or even how to state it in proper P&P form (in small text under item 1 in Section 4.2.1? or is that not normative?). As TF chair I've been enforcing this "policy" for years and it's not an unreasonable policy at all – even if it's only de facto. It ensures that we never have a situation in which an RFP (posted by the 4 wk deadline) is reviewed by the AB and the purported issuing TF is completely unaware of its existence or content.

Need to also make it clear that an RFP may not be voted for issuance by the AB without first being recommended for issuance by the issuing TF via a formal vote. Unless it's stated elsewhere in the P&P, this statement in the P&P as it stands now is too weak:

1. An RFP is usually drafted by the Task Force responsible for that
technology area, and passed to the TF's parent TC for issuance.

Btw "usually drafted"?? Why "usually"? Is this to cover the case where a SIG prepares an RFP and brings it to a TF to issue? Suggest adding something in small text to explain what is implied by "usually".

It is a (very) long standing practice to have new RFPs presented and discussed in the issuing Taskforce at least one meeting before the meeting in which the RFP is reviewed by the Architecture Board and eventually issued by the Technical Committee parent to the originating Taskforce. This common practice proved very valuable, but is nowhere mandated in the current version of the P&P.

I suggest to insert at the appropriate place in section 4.2 of the P&P the sentence:

"RFPs must be presented to, and discussed in, the originating Taskforce at least one meeting prior to the meeting, in which the RFP is intended to be issued by the Technical Committee parent to the originating Taskforce."

The OMG uses the term of 'white ballot'. This term could be offensive to some audiences and should be officially renamed within the OMG. Perhaps 'blank ballot' could be used.

This is related to ABPSC-56

Groups have frequently used camelCasing for naming elements in specifications, but certain environments (SQL) are case-insensitive, and conversion of camelCase names into these environments is lossy.

Consider whether camelCase can be recommended as a best practice in light of this.

The (primary) CMMN 1.1 XSD schema is published at this URL:
https://www.omg.org/spec/CMMN/20151109/CMMN11.xsd

which should be de-referenced from a URI such as:
https://www.omg.org/spec/CMMN/20151109/CMMN11/

Nevertheless, the schema itself is bound to a namespace:
http://www.omg.org/spec/CMMN/20151109/MODEL

which is not de-referenceable

It is possible that the schema and its namespace were published before OMG reorganized the URL/URI architecture and started to enforce de-referenceability.

Similar issues are likely to exist across the other CMMN schemas, and/or related specs such as DMN (1.1, 1.2)

During OMG meetings, we often perform voting using a process that involves passing motions based on unanimous consent. This process is known as a 'w***e ballot' which is not a term that I have found in the OMG P&P or Robert Rules of Order.

Can this process be documented officially in the P&P?

The current version is not functioning properly and is essential for specification validation.

We seem to ask for a post-finalization BCQ in addition to the post-adoption one.
Requiring an additional one makes little sense to me and seems somewhat of a process absurdity – is that something the Board really requires?
Surely all that's needed is commitment that the Finalized spec is implemented.

I also think it’s absurd to require a new BCQ for each minor revision. If someone is committed to implement the Finalized spec, it's reasonable to assume they're going to implement the spec with bugs and ambiguities fixed!

Finally the BCQ does not ask for any more detail than "an implementation". Since most specs have several conformance points it seems useful to ask a further question about which will be provided. More useful IMO than asking about platform.

Looking at the P&P it does not seem clear, and only seems to require one BCQ at time of adoption (which also applies to Finalization).

For RFCs only step 6 says:
[When the TC adoption vote begins the submitter(s) can expect to receive the
standard Questionnaire from the Board’s Business Committee asking about
IPR ownership of the Specification and commercial availability of
implementations, and requesting a grant of copyright for publication.]

The only other mention seems related to Veto power in 4.4.1.3:
[this judgement is usually made by the Board's Business
Committee, based upon responses to a questionnaire sent to submitters
whilst the TC adoption recommendation vote is in progress.]

As per ABPSC-52, Working Groups are currently ad hoc convenient fictions for Subgroup Chairs to organize their members into groups to perform specific tasks.

However, without clear guardrails and guidelines, they have mutated in some cases to use cases for which they were never intended.

It may be useful to clarify what a Working Group is, in the original intended sense, so that there are clear processes to follow. This definition should probably be added to the Subgroups (Section 3.7), perhaps with a quick definition in Section 2.

('Other' use cases such as described in ABPSC-52 will be supported through mechanisms yet to be determined. Defining Working Groups here does not immediately eliminate those other use cases, it simply clarifies which need special handling.)

The OMG P&P ( https://omg.org/pp/ ) makes clear that OMG Member communications are to be kept Member only. Non-Members may be invited to join Subgroup meetings as Guests, on a case by case basis, but OMG communications are one of the benefits that Members pay for. We archive them for later reference, and they are a community resource.

ALL official OMG groups – and therefore their mailing lists – are members-only. Period.

Working Groups snuck through as an undefined case. Seriously, take a look in the Bylaws and P&P, they do not exist in those documents. They were only ever intended as a convenient fiction for Subgroup Chairs (Task Forces, Subcommittees, Special Interest Groups) to organize their OWN​ members into groups to perform work on behalf of the Subgroup, and to be dissolved upon completion. Without an official process, it was felt that this gave Chairs the flexibility to spin up a subset of their Subgroup, direct them, and have them report back in a more nimble fashion.

Unfortunately, things got a little out of hand. Somewhere in the past few years, Working Groups took on a life of their own, and have been operating without meaningful process or boundaries, including inviting non-Members into OMG Members-only spaces and communications as a regular part of their operation.

This was never the intent, nor the purpose of Working Groups, and the practice needs to be curtailed. Working Groups that continue to operate as strict subsets of the Membership are fine, and MARS DTF's Working Groups are good examples of these. (Remember, non-Members may​ be invited in, but please refer to Section 2 of the P&P for the definition of Invited Guest. It is not open season to CC or BCC at whim.)

However, those Working Groups that are intentionally comprised of Member and non-Member individuals pose a problem. They blur the line between Member and the public, and weaken the benefits of being an OMG Member, as well as our ability to ensure adherence to the OMG IP policies that govern our communities.

They can, of course, also serve a meaningful purpose in outreach and generating interest in OMG operations, and because of that we have been trying to find a way to support these endeavors without continuing to bruise the OMG Membership obligations that we have.

The compromise was that newly formed WGs could – by request and approved on a case-by-case basis – be set up as open for a one-year time period, to engage with the public and generate interest, as long as the mailing list was the primary form of communication for the WG. At the end of that year, they would join the remainder of the WGs in being closed to the public, and available only to Members.

Not all WGs have been bound by even this, however.

We need a well-formed replacement for such cases, or consider simply enforcing the original intent of WGs, and keep them 'closed', and Members only.

Some specifications, here DDS, constitute a "family of specifications". It would be very helpful for users outside and inside OMG if the pages would provide cross-reference links. In this case, the main specification, DDS, should provide links to all related subordinate specs, like DDS-DLRL for example. In turn, the subordinate specs should provide a link to the main specification (DDS in this case).

While using DDS here, the same scheme holds for many other families of specifications. For example MOF (SMOF, MEF, MOFOL, ...), FUML (PSCS, PSSM, ...), and the big CORBA and IDL family, (and more)

Our Specification catalog is missing machine-readable files all across the board! Today alone I found XMI.xsd missing from XMI 2.5.1 and DG.xmi missing from Diagram Definition (DD) 1.1. And I had asked to restore other machine-readable files in the past...
This is a very dangerous situation. I suggest we create an ad-hoc working group to g with a fine-tooth comb over the specification catalog. But this WG need to be people WHO KNOW THE SPECIFICATIONS. This cannot be delegated to staff. In all cases I encountered so far, all files were available from submitters / FTF / RTF, but only partially uploaded. WE NEED TO FIX THIS QUICKLY. I'm ready to help...

The RFI process described in the P&P (4.2.2) has an underlying assumption (or at least that is the perception among members) that it will be send out as a formal document, and companies will send back responses that have been legally vetted, as the 'voice of the company', on generally a months-long schedule.

Sometimes we simply want to know what individuals think, on a shorter time-frame, and this process is not amenable to that.

Requests have been made by three separate members on individual occasions in the past month for an 'RFI Lite', consisting of a simple web questionnaire that can be filled out by individuals not speaking on behalf of an entire company.

Discussion needs to happen on what the changes to the existing RFI process need to be, or if this is acceptable as the P&P is written, and is instead a matter of member education and introduction of appropriate support infrastructure.

The P&P uses two terms to discuss the presence of a representative at a meeting (of any sort): 'attend' (present tense) and 'in person' (past tense). The meaning is clear from context that it is an individual who has engaged in a meeting.

Given that many (most?) of our meetings now incorporate a dial-in line or online screen presentation tool of some sort, it is important for us to reflect this shift.

Suggestion to add language specifying that online engagement (with bidirectional communication capability, voice, typed, or both) counts for purposes of attendance, including 'in person', and that attendance records should include anyone calling in to a meeting.

Section 3.3 would be a good place to add this, as it currently does not exist.

The key sentence about not allowing an electronic poll concerning a referral to the parent TC of the subgroup is a little buried down this long section 3.7.3, and as we saw recently, it can be overlooked.

Before discussing how a vote happens, and who can vote, it would seem logical to start by stating what can be voted on that way.

The suggestion is to move the sentence “A Subgroup poll on a recommendation to the parent TC shall occur only at Subgroup meeting that is co-located with meetings of that TC” closer to the beginning – either before or after the first paragraph, which also concerns types of polls that a subgroup may conduct.

In addition, that sentence is missing the article "a" in "... only at a Subgroup meeting ...".

(Note: I thought this had been entered early in the life of the ABPSC, but I can't find it)

The boilerplate disclaimer on the cover page of a discussion paper considerably weakens the authority of the paper. While it is appropriate to tell the readers that the paper is not a specification or other Board-approved deliverable, the disclaimer fails to recognize the value of a paper developed by members, often at considerable effort, and reviewed and approved by a Task Force.

The suggestion is to balance the current text by including more positive encouragements to treat a Discussion Paper as the well-considered opinions and/or recommendations of a body of experts. I am not proposing specific replacement text right now, but would be willing to participate in this effort if the issue is deemed to have merit.

Section 4.4 of the RFP, which describes the required Letter of Intent (LOI), treats the use of the OMG's LOI template as a suggestion.. not a requirement. This is not a good idea. Should be a requirement to ensure that the legally binding words contained in the LOI template are provided in a consistent way. In like fashion, it should be clear (stated somewhere – P&P?) that the same applies to RFC submissions – that use of the OMG's LOI template is not a suggestion but a requirement.

The Cyber Security RFI (and I suspect most others) includes the following in section 3.2 How to Respond:

Acceptable formats are ODF (ISO/IEC 26300), PDF (ISO 32000), ISO Latin-1 (ISO/IEC 8859-1) or MS Word .doc or .docx files.

ISO Latin-1 is not a format but a character encoding so does not seem to fit in this list alongside the other options. Is any word processing or file format OK so long as it uses that character encoding? Why not also include UTF-8? I think we should just delete this as an option.

Section 3.5.4 states that "There are no proxies for electronic polls, but neither is there is a time limit - instead, the ABC must continue gathering votes until no further voting could affect outcome."

Since AB members may change their votes at any time prior to closure, this sets up a never-closing vote.

By traditional fiat, a two week window has been used by the AB Chair. Codify this, or clarify the above language.

P&P Section 4.4.1.1, paragraph 4, defines the circumstances under which "an RTF may respond to an Issue by proposing an extension that adds functionality to a Specification." However, this allowance is limited to RTF's whose report is "delivered before 15th September 2020". The AB should review the policy as it stands well before this sunset date and decide whether to recommend that the subject policy be made permanent.

There is a common understanding on the AB that documents must be in English, and must be in American dialect.

There is no such stipulation in the P&P.

4.2.1 Outline of RFP Process: 

• Step 4:  The membership list for voting on issues related to the RFP may be closed, as described in section 3.7.4.1.
• That section does not exist... likely means to refer to Section 3.7.3 Subgroup Polls
  This is the only reference to the section number.

The current copyright license that respondents to an RFI place in their response is included in the RFI template v1.6 (omg/19-07-01).

The current text is:

We hereby grant OMG the right to make an unlimited number of copies of the Copyrighted Material as part of the OMG adoption process.
We hereby grant each OMG member the limited right to make up to twenty-five (25) copies of the Copyrighted Material for review purposes only as part of the OMG adoption process.

It has been pointed out that this makes no claim of revocability or irrevocability of the material provided in an RFI response, and that the concept of 'copies' of the material is less meaningful in the age of primarily digital documents.

This license should be redone to reflect current distribution mechanisms, and clarify the revocability (or not) of information supplied in the response to an RFI.

Templates derived from the P&P need review & updating (all templates in https://www.omg.org/technology/template_download.htm
eg. LOI, RFP, RFC, RFI

Many links are out of date. Check for https:, dead links, wording clarity.

We need a timeline for each specification and submission, indicating the actual state a submission/specification is in at a given point of time to allow traceability.

While being a submission, revised submission dates provide some information about its state, same is true while in FTF. But after that are several steps until the spec ends up in the Formal Specification Catalog, and sometimes it takes significant time for these last steps, and nobody can give an answer why it takes so long and what can be done. A simple "State Machine Display" would be very helpful to see the state a document is in, and what could be done to help accelerate its processing.

As it stands now an RFP remains in existence after all its deadlines are passed... its a Zompie RFP which theoretically can be reactivated by resetting its schedule... but for the most part they linger in the database as an active process; which its not.

As soon as a submission is adopted and moves into FTF state, the link to the soliciting RFP disappears from the Work-in-Progress page, and finding the correct RFP turns often into a cumbersome search in the document repository. Therefore, every RTF and FTF section shall retain the link(s) to the responsible RFP(s).

The same is true for the Specification Catalog. While RFPs are public documents, we may not want to make them public for formal specifications since the actual specifications may have diverged/evolved from the original requirements over time, but the member-only version shall have these links in, either the History, or in a new RFP section of the catalog entry. This would aid the work of members, and in particular the AB a lot.

There are inconsistencies in the two definitions of the RTPS Encapsulation Header I've found so far. The major issue is that the values for the encoding identifiers are different between 7.4.3.4 and 7.6.3.1.2 for non-XCDR1 encodings. These are the big-endian values compared:

The other issue is that while 7.6.3.1.2 describes the two options bytes of the encapsulation header that follow the encoding identifier and extends it for padding info, 7.4.3. is lacking in details as far as I can see. The serialization rules has them in 7.4.3.5.3 as `OPTIONS`, but doesn't define it in any of the tables before the rules like all the other symbols are. It does mention encapsulation in 7.4.3.5, but doesn't mention anything about extending the options bytes.

I've just today come to the embarrassed realization that I've been assuming for years (my bad!) that RFIs (issuance of) are not subject to the 4 wk rule. That folks can decide during a meeting week to prepare an RFI and get it issued that same week. And I've been spinning what I realize now is a fairy tale for years. After reviewing the P&P today (and the HH Guide), my opinion is that the P&P's handling of the 4 week rule is quite clear on the subject of submissions but with regards to documents like RFPs, RFCs, and RFIs is quite obtuse. It does not state explicitly which documents issued by a subgroup are subject to the 4 week rule – all it says is "Where a poll at a meeting requires documentation (i.e., on adoption of particular documents or based on the content of a document), one third of the Voting Members represented at the meeting may invoke the requirement that documentation supporting the poll must be available at least four weeks prior to the poll." This may be OK in the sections concerning the AB polls (Sxn 3.5.4) and DTC/PTC polls (Sxn 3.5.2) but IMHO is not OK for subgroups. One is forced to infer that "based on the content of a document" refers to things like RFPs, RFCs, and RFIs. A subgroup chair should not be forced to have to infer the intent of some obscure line in the P&P .. it should be clear. It also doesn't state clearly that the 4 wk rule applies – all it says is that somebody can choose to invoke it, if they wish.

My suggestion is that the wording of the paragraph cited above should be changed to indicate exactly which documents are subject to the 4 week rule. Am referring here to the ones covered by "based on the content of a document" ("adoption of particular documents" clearly refers to submissions). One could also add the qualification that the 4 wk rule applies to any document voted on by a subgroup that will subsequently be voted on by the AB and TC or the TC alone. Furthermore, the wording should be more direct... clearly state the cases where a 4 wk rule applies instead of stating it indirectly (almost backwards or by exception) – "Members represented at the meeting may invoke the requirement that documentation supporting the poll must be available at least four weeks prior to the poll." This makes it sound like one can ignore the 4 wk rule unless somebody objects. In which case what kind of a rule is it?

I know we've operated under this subtle wording for years .. but let's abandon subtlety for clear and direct. Please!

Have inspected the P&P for the deadline for submitting a request for a Vote to Vote. It is commonly understood that it needs to be 4 weeks in advance (so says Juergen's emails prior to each meeting) but where is this requirement codified? Right now, the only place where the rules governing a Vote-to-Vote are described is in the Hitchhiker's Guide (V7.8) but that is not a normative document – just a guide. It really needs to be in the P&P.

A recent discussion on the AB mailing list led to the following observations regarding Submitters, Supporters, and Contributors in OMG Submissions:

1) Sanitized description of issue, from a non-public example
Contributor was defined as a Participating Organization who is not a Submitter. Submitter is defined as OMG Member who provides an LOI. Participating Organization is defined as anyone who signs onto the agreement. Document states that all POs are bound to the IPR, at least in intent.

PartOrg = IPRBound
Submitter = OMGMember && LOI
Contributor = !Submitter = !(OMGMember && LOI) = !OMGMember || !LOI

Contributor => IPRBound && (!OMGMember || !LOI)

So a Contributor could be either: not an OMG Member, or an OMG Member who didn’t file an LOI. Since not filing an LOI is supposed to be a non-starter for contributing, I assumed this was to include non-OMG Members in the process. (Additionally, if they’re not an OMG Member, then can they even file an LOI?)

In all cases, a Contributor is bound by the IPR, which is intended for those contributing IP. All signs point to this being a back-door for IP-contributing non-OMG Members. Please correct me if I’m wrong. If wrong, then this entire thing gets easier, because....

2) IPR Definition of ‘Contributor’ vs. ‘Member'
Document: https://omg.org/cgi-bin/doc.cgi?ipr
OMG Doc #: ipr/12-09-02

IPR 1.2: "Certain OMG members who participate in the development of OMG Formal Specifications make commitments to license their IPR as set forth below.”

--> This applies to OMG members only.

This is supported by:

IPR 8.1K: "“Obligated Party” means an OMG Member that has incurred a Contribution Obligation or a Participation Obligation. “Obligated Party” includes Affiliates of the OMG Member.”

IPR 4.4A: "Obligated Parties. OMG Members are Obligated Parties only under the following circumstances:"

However, in other places OMG membership is left completely out:

IPR 2.1: "Each contributor of any material to an OMG Specification is [...]”

--> ‘contributor’ is never defined as exclusive to OMG members.

IPR 3.2A: "Contributors. Anyone who makes a Submission or Contribution to an OMG Specification [...]”

IPR 8.1D: "“Contribution” means any written submission in response to an RFP or RFC, or to an FTF or RTF, that is intended to be included in an OMG Formal Specification. The variants “Contribute” and “Contributor” are subject to this definition."

--> This is as close as it gets.

The way it reads, non-Members can theoretically contribute, but only OMG Members can be bound to obligation under 4.4.

The Document appears to extend this to non-members, but it isn’t precisely clear, and it would be sloppy to leave this to the legalese authoring skills of each team, don’t you think?

Currently in the P&P (https://www.omg.org/cgi-bin/doc.cgi?pp/17-06-01)/ IPR:

• Submitters are:
  • OMG members
    and
  • have previously submitted an LOI
    and
  • have contributed IP, and are bound by the IPR
• Contributors are a somewhat defined entity of unclear OMG membership, but who are bound by the IPR, in theory
• Supporters are an undefined non-entity

Desired:

• Submitters are:
  • OMG members, able to put forth a specification for voting
    and
  • have previously submitted an LOI
    and
  • have contributed IP, and are bound by the IPR
• Contributors are:
  • NOT OMG members, not able to put forth a specification for voting
    and
  • have contributed IP, and are bound by the IPR
    and
  • MAY have previously submitted an LOI <--- This was unclear in the SysML2 Agreement. See 1) above
• Supporters are defined as:
  • NOT having contributed IP, and therefore not involved in the IPR (or have formally withdrawn the IP)
    and
  • NOT submitted an LOI (or have withdrawn it via notification of intent to TechDir (P&P 3.7.2 and IPR 5))
    and
  • OMG status is irrelevant <--- Curious on thoughts here [1]

As per IPR 5, once a Member contributes IP, they are bound to the Contribution Obligation. This is clear, but it is not clear what the outcome is for a non-Member Contributor, if such a thing is being allowed. Non-members cannot be on an Adoption Process Voting List (IPR 8.1B), but withdrawal from an Adoption Process Voting List is the single trigger for establishing the outcome of obligation with respect to IP in IPR 5.2. I see a loophole. The Document appears to pull in Contributors to this process, and I think that is the intent, but again, it’s not precisely clear.

To get back to the original Submitter vs. Supporter (vs. Contributor) question:

A Member signs on as Submitter, contributes IP, then lets their membership lapse. They’re no longer able to be listed as a Submitter, but they still need to be clearly bound by the IPR in the specification. Contributor would suffice here. If the Contribution Obligation is in effect, then the organization should be listed as Submitter or Contributor, based on OMG Membership.

An organization can drop to a theoretical Supporter status only if clause 5.2C is met, neither Contribution nor Participation Obligations.

I think that having this be clear would be an improvement. Supporters should be, IMO, bystanders who support the effort but who did not contribute to the creation of the document in a way that would worry their internal legal staff.

[1]
Allowing non-OMG Members to sign on as Supporters at will is a nice gesture, but requiring membership to do so could help drive, well, Memberships. One for the BoD, I think.

Larry had the following comment:

There is no such thing as a supporter in P&P. Supporters are cultural artifacts and have no standing. There are only submitters... however; under IPR (see Jason's [comments]), submitters are responsible for the IPR claims on material in the submission, hence stuff rolls downhill should someone else contribute... and note there is no requirement that contributors be declared (as are the Supporters with no standing) unless there is an issue/condition to be declared under the IPR agreement.

Request that a new Request for Curation Inclusion (RFCI) process template and associated document template be created to support the review and vetting of reusable content that is considered valuable to our OMG communitiy. Examples of content include FIBO updates, CubeSat Reference Model (CSRM), other domain model examples, libraries, and methods. Our current RFP process ab-18-12-10 RFP, is not appropriate for non-language content but could be tailored and streamlined to support the review, approval, maintenance and archival of content that is generated using OMG specifications (OMG UML, SysML, UAF, BPM....).

Curation: 1. The action or process of selecting, organizing, and looking after the items in the collection.. 2. The selection, organization, and presentation of online content, merchandise, information etc., typically using professional or expert knowledge.