| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | # | Origin | Issue | Resolution | BB Sections | EA Model | File Schema | XML Generator | Status | Notes | ||||||||||||||||
2 | 1 | CC review of XML email 17/4/23 (1) | PlanStatus reference on the status field of the updatePlanStatus operation does not exist | Typo in Blue Book, corrected in Blue Book | 4.6.5 and others | N/A | N/A | N/A | Corrected in H5 | |||||||||||||||||
3 | 2 | CC review of XML email 17/4/23 (1) | There are types such as “Identifier[SubPlan]” and “Identifier[Domain]” that cannot be interpreted correctly | Use of Identifier[SubPlan] and Identifier[Domain]: these are errors in the Blue Book – this usage of Identifier[Type] should have been removed, but some cases remained. 3 cases of Identifier[SubPlan] and one of Identifier[Domain], replaced by Identifier. | various | N/A | N/A | N/A | Corrected in H5 | |||||||||||||||||
4 | 3 | CC review of XML email 17/4/23 (2) | The abstract classes are being generated with: shortFormPart="0”. There must be no shortFormPart in your abstract types. | Update XML Generator to suppress SFP for abstract types. | N/A | N/A | N/A | Updated | Corrected in XML Generator for H5 | |||||||||||||||||
5 | 4 | CC review of XML email 18/4/23 | Typo in the requestSummaries field of the getRequestSummaries operation. Missing final “s” . | Typo in Blue Book, corrected in Blue Book | 4.2.6 | N/A | N/A | N/A | Corrected in H5 | |||||||||||||||||
6 | 5 | CC review of XML email 18/4/23 | ObjectRefs are not being defined correctly. They should point to the MPS area, instead of the ObjectRef MAL area | Following discussion, it was agreed that for an untyped reference, the area should be MAL, but for a typed reference it should be that of the specified type [MPS]. For MPS, ObjectRef will continue to be marked as MAL in both cases, change will be made in the XML Generator | N/A | N/A | N/A | Updated | Updated in XML Generator | |||||||||||||||||
7 | 6 | CC review of XML email 18/4/23 | ObjectRefs can be represented in XML as ObjectRef(Type) rather than using angle brackets. | Following discussion, it is confirmed this only affects XML. As it improves readability of the XML an update will be made to the generator. | N/A | N/A | N/A | Updated | Updated in XML Generator | |||||||||||||||||
8 | 7 | CC review of XML email 20/4/23 | In line 1973, your type is set as: <mal:type area="MPS" list="True" name="Activity Details"/> You need to remove the space character in the name of the type, to: <mal:type area="MPS" list="True" name="ActivityDetails"/> | Looks like a simple typo in the Blue Book | 3.2.2.3 | N/A | N/A | N/A | Updated | |||||||||||||||||
9 | 8 | CC review of XML email 20/4/23 | In line 3438, you have the type: <mal:type area="MPS" list="False" name="RelResourceProfile {redefines value}"/> Maybe it is some kind of note that you left in your Word document. Also, RelResourceProfile, does not exist, only RelativeResourceProfile. So, I replaced with: <mal:type area="MPS" list="False" name=" RelativeResourceProfile"/> | Correct substitution – looks like the Blue Book needs an editorial update. | 3.3.6.1 | N/A | N/A | N/A | Updated | |||||||||||||||||
10 | 9 | CC review of XML email 20/4/23 | In line 1215, you have the type: <mal:type area="MPS" list="False" name="MPSSystemConfig"/> This type does not exist in the xml. I found MPSSystemConfigDetails, so I replaced it with it: <mal:type area="MPS" list="False" name="MPSSystemConfigDetails"/> | Correct substitution – it looks like the Object name was changed but not propagated through to where it was referenced. Blue Book needs to be updated | 4.5.13.1 | N/A | N/A | N/A | Updated | |||||||||||||||||
11 | 10 | CC review of XML email 20/4/23 | Your xml is referencing a type User in some of the structures. This type does not currently exist in your xml file, please create it. | These should be referencing PlanningUser, which does exist (name was changed at some point). Update Blue Book to correct. | Multiple Locations | N/A | N/A | N/A | Updated | |||||||||||||||||
12 | 11 | CC review of XML email 20/4/23 | I noticed that some comments are just written as “E1: ” or “E4: ” (…) Probably some xml generation problem. Please have a look on it. | We discussed this at the Fall Meeting. Support for certain parts of the MPS Information Model is optional – a bit like capability sets for Services. You suggested we flag this in the comment field, which I have done by beginning the comment “En: “ where n is the number of the element set defined in the Blue Book. You can then interpret this in your browser to display the Element set as a distinct field. If there are comments which only have this, this would be because there is no associated comment with the data structure, so the only thing in the comment is the element set tag. | N/A | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
13 | 12 | CC review of XML email 4/5/23 | Representation of Lists of ObjectRefs: proposal for 3 different representations, including support for lists of types within ObjectRefs. | Following discussion, it was agreed to keep it simple. A List of ObjectRefs will be represented as for any other List. Lists of types within an ObjectRef will not be supported. | N/A | N/A | N/A | Check Consistent with #5 | No Update Required | Was already consistent with agreed approach. | ||||||||||||||||
14 | 13 | MAL Update CC email 15/5/23 | Explicit Nullability Column to be added in Operations Tables for message fields. | Update Blue Book Operations Tables to include Nullability column. Assign Nullability (assumed No in most cases). Update XML Generator to apply the nullability column. Format provided 16/6/23. Change in format of message fields noted - unclear if this is a compulsory change. | 4 All Operations Tables | N/A | N/A | Updated | Updated | Tables updated by macro to add Nullability column. Had to turn change tracking off for this, as otherwise tables were corrupted on save. Further manual edits were required for multiple message fields. All fields are non-nullable. Change to representation of message fields not addressed. | ||||||||||||||||
15 | 14 | MAL Update CC email 15/5/23 | Lists cannot contain Null items | Not an issue for MPS. Would not expect Null items to be added. Assume List can be empty. | N/A | N/A | N/A | N/A | No Action | |||||||||||||||||
16 | 15 | MAL Update flagged by PvdP | MAL::ObjectIdentity - Area and Type codes to be removed as are implied by the object itself. | Uncomfortable with this change, which seems driven by encoding rather than the abstract information model. However, it appears this has been agreed by the SM&C WG. Generic sections of Blue Book on MO Objects will need to be updated for consistency. EA Information Model will need to be updated for consistency. File Schema may need to be modified to include this information as not contained in the ObjectIdentity - leading to inconsistency between File Format and MO Service Model MPS WG agreed to maintain consistency between MO Service and File Format Models and rely on it being apparent from context what the Area and Type are in the File Format case. | 3.3.1 3.4.2 | Updated | Updated | N/A | Updated | Confirm this is happening at SM&C WG telecon. Need to assess how to handle in File Formats: 1) Retain Area & Type in the MAL Types schema - introducing a difference with MPS Services. 2) Rely on it being apparent from context what the Area and Type are. 3 MPS Object types are embedded in MPS File Formats: Plan, ActivityInstance and EventInstance (the latter two within a Plan). | ||||||||||||||||
17 | 16 | Marvin Wittschen email 14/4/23 | What should be the source of an activity instance that is inserted with the insertActivity operation? | Propose the PlanningUser that inserts it. Clarification to be added to Blue Book for ActivityInstance. Note EventInstance does not have a source field. | 3.2.2.1 | N/A | N/A | N/A | Updated | Also check InsertEvent | ||||||||||||||||
18 | 17 | Marvin Wittschen email 14/6/23 | RequestInstance:: outputPlanRef is defined as a list of ObjectRefs, but RequestSummaryStatus:: outputPlanRef is only a single ObjectRef. | This is an inconsistency. Update field in outputPlanRef in RequestSummaryStatus to be a List. Also affects PlanningResponseFile format. | 3.2.5.3 Figure 22 | Updated | Updated | N/A | Updated | Check has been updated. | ||||||||||||||||
19 | 18 | Marvin Wittschen email 14/6/23 | ActivityNode:: activities is a list of "Activity Details" (including a space). | Typo in Blue Book, correct in Blue Book (same issue as #7 noted by CC) | 3.2.2.3 | N/A | N/A | N/A | Updated | |||||||||||||||||
20 | 19 | Marvin Wittschen email 14/6/23 | ComplexResourceConstraint:: value is defined as "RelResourceProfile {redefines value}". Should it be “RelativeResourceProfile” instead? | Blue Book table has not been updated in line with Model. Attribute should be named valueProfile and type should be RelativeResourceProfile as you identify. (same issue as #8 noted by CC) | 3.3.6.1 | N/A | N/A | N/A | Updated | |||||||||||||||||
21 | 20 | Marvin Wittschen email 14/6/23 | getSystemConfig has parameter MPSSystemConfig, but only MPSSystemConfigDetails is defined. | The Object name was changed but not propagated through to where it was referenced. Blue Book needs to be updated to MPSSystemConfigDetails. (same issue as #9 noted by CC) | 4.5.13.1 | N/A | N/A | N/A | Updated | |||||||||||||||||
22 | 21 | Marvin Wittschen email 14/6/23 | In Section 3.3.3 of the blue book, figure 34 still shows the different expression types which were converted to subtypes. | The following text explains that at the MAL level this is handled by polymorphism of MAL::Attribute at the MAL layer and there are no formal subtypes, only the concrete type Expression. | N/A | N/A | N/A | N/A | Closed by Answer Figure Title Updated | Change Title of Figure to Example Sub-types of MPS Expression | ||||||||||||||||
23 | 22 | Marvin Wittschen email 14/6/23 | Section 7.3 still contains a reference to TimeExpression | Replace by "Expression of type Time" | 7.3 | N/A | N/A | N/A | Updated | |||||||||||||||||
24 | 23 | Marvin Wittschen email 14/6/23 | With the current XML, a list of ObjectRefs of a type is generated as a single ObjectRef of a list of a type. | If I understand the point, this has been further discussed and simplified. See #12 above. Cesar confirms the following: List<ObjectRef(MyType)> encoded in XML as <mal:field name="aaa" nullable="False" comment="A comment"> <mal:type area=" MyArea" list="True" name="ObjectRef(MyType)"/> </mal:field> | N/A | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
25 | 24 | Marvin Wittschen email 14/6/23 | How should an ObjectIdentity be converted to an ObjectRef? Both types contain area, key and type but ObjectRef contains a domain as String, but ObjectIdentity contains a list of Identifiers. | Response from CC: Domain should be represented as a List of Identifiers (has been corrected in MAL). MAL implementation provides a function to generate the ObjectRef, to preserve encapsulation. RST: MPS Information Model Blue Book updated to ensure consistent representation of Domain as a List of Identifiers, in service data structures. 4 structures affected RequestFilter, PartialPlan, PartialPlanFilter and PlanFilter. See note regarding usage in Service Operation messages. | 3.2.5 Request Filter 3.2.6 Partial Plan; Partial Plan Filter; Plan Filter | Updates consistent with BB | N/A | N/A | Updated | Note: have updated 4 "filter" classes to make Domain a List of Identifiers as an ordered list representing a domain hierarchy. However, we have several operations with a field "domains" where it is implied each is a separate domain. Recommend we change the interpretation of these to only allow the Domain hierarchy list. Assume a single ordered list representing a domain hierarchy with optional wildcard - explain in text. | ||||||||||||||||
26 | 25 | Marvin Wittschen email 14/6/23 | All monitor operations accept the keys as a single Identifier. How should an ObjectRef / ObjectIdentity be converted to an Identifier. | My understanding is that the Identifier is the Key field of the ObjectIdentity. Domain is a separate subscription field. Area and Type are implied by the Subscription Key. If filtering by Version is required, this would need to be done as a separate Subscription Key. | N/A | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
27 | 26 | WG Review Maria Wörle 10/5/23 | question from the WG: how is this table connected to the PICS table? | PICS Items D.1 to D.8 correspond to the rows in this table. Add reference to table in the PICS annexe. | 2.6 Table 11 Annex A | N/A | N/A | N/A | Updated | |||||||||||||||||
28 | 27 | WG Review Maria Wörle 10/5/23 | Reference to Table 11 incorrect | Reference field needs to be updated. Update all fields in document. | 2.6 | N/A | N/A | N/A | Updated | |||||||||||||||||
29 | 28 | WG Review Olly Page 18/5/23 | Some things are in American locale, others English. Do we need to decide on one? | CCSDS requires American locale. I have set the language to American English, but occasionally inserted text may revert to British English. I am tempted to rely on the secretariat to correct any further errors, but I will do a find and replace on grey. Turns out although gray is the normal spelling in the US, grey is an accepted alternative, which is why it did not fail the spell checker. No change made. | General | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
30 | 29 | WG Review Maria Wörle 10/5/23 | question from the WG: how is this table connected to the PICS table? | The capability sets identified here are reflected in the rows of the PICS table. Will add reference to this table in the PICS Annexe. | 2.6 Table 12 Annex A | N/A | N/A | N/A | Updated | |||||||||||||||||
31 | 30 | WG Review Maria Wörle 10/5/23 | Please explain why exactly this selection is made | This corresponds to the optional information model elements identified in the previous table. This is explained in the text above, but I will attempt to clarify. | 2.6 Table 12 Columns | N/A | N/A | N/A | Updated | |||||||||||||||||
32 | 31 | WG Review Maria Wörle 10/5/23 | Is this column filled completely/correctly? This whole section apparently has to be explained to us | I will check it is still valid. As this is a summary, I did not want to reference specific Data Structures that have not yet been introduced, but to give some idea of which Data Items are referenced in the Service Operations. It seems I need to improve the explanatory text above this table. | 2.6 Table 12 Final Column | N/A | N/A | N/A | Updated | |||||||||||||||||
33 | 32 | WG Review Maria Wörle 10/5/23 | Planning Request? | Was abbreviating to be concise. Same could apply to Activity, Event and Resource, which would make the entries multi-line and greatly expand the table. I will change it for Planning Request. | 2.6 Table 12 Final Column | N/A | N/A | N/A | Updated | |||||||||||||||||
34 | 33 | WG Review Christoph Lenzen 09/5/23 | has a different name in the diagram (executionDefinition) | Change was requested to remove abbreviations. Was updated in model, but not in Blue Book. Correct in Blue Book to executionDefinition Note also applies to execInst in ActivityInstance and ActivityUpdate. | 3.2.2.1 Activity Definition Activity Instance | N/A | N/A | N/A | Updated | |||||||||||||||||
35 | 34 | WG Review Christoph Lenzen 09/5/23 | where and how is this referenced object defined? | Applies to ActivityDefinition, ActivityInstance and ActivityUpdate We do not specify - it is external to the MPS Information Model. It might be defined in the MO Automation Information Model, or it could be an implementation specific identifier for an automated procedure. | 3.2.2.1 Activity Definition Activity Instance 3.2.2.2 Activity Update | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
36 | 35 | WG Review Christoph Lenzen 09/5/23 | For Plan Edit service, the entity using the planEditService function should be stored as `source`. The planningUser however has wrong type `ObjectIdentity`. How is the source inferred (also for the other service operations)? | See also #16 above. PlanningUser to be added as a possible type in the case of insertion using the Plan Edit Service. PlanningUser is an MO Object, so you can reference it using an ObjectRef. | 3.2.2.1 Activity Instance | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
37 | 36 | WG Review Christoph Lenzen 09/5/23 | What's the difference between Null and the empty list? I'd recommend making this non-nullable | I tend to agree with you. Furthermore, SM&C have clarified that Lists cannot contain Null items - which this might be taken to imply. I will systematically make Lists non-nullable. (I have not replied to the same comment elsewhere). See point #14 above. | 3.1.4 added Nullability of service operation List fields reviewed. | N/A | N/A | N/A | Updated | Modify approach. Use nullable list in the filter case to mean no filter. Otherwise revert to previous nullability. Add text to explain distinction between null and empty list in the case of a filter. | ||||||||||||||||
38 | 37 | WG Review Christoph Lenzen 09/5/23 | Why should the user of `updateActivity` (PlanEditService) want to set an `errorCode` and `errorInfo`? | I doubt that he would - they are optional fields, but there is no particular reason to disallow this, and we don't want to unnecessarily have to define an additional data structure. | 3.2.2.2 Activity Update | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
39 | 38 | WG Review Olly Page 18/5/23 | I don't see why this is a composite type, but it looks quite complicated in code/xml since you just have a single float inside a structure. The MAL is missing an "offset", or delta time (they are using a negative duration for this) - but the solution is probably to have an offset time in the mal. It's probably not a float, but the same units as the underlying time type. | DLR introduced this concept some years ago. It captures not just the type, but the rules on its interpretation. To remove would require substantial change to the document for little benefit. | 3.3.4 Slider | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
40 | 39 | WG Review Olly Page 18/5/23 | This is a bit overloaded, since every singular argument will be in a list of size 1. Secondly a list of arguments can't be uniquely named - they just look like an array of possibly different types. Maybe it would be better to have a singular argument type and a separate argument list, since that's the way most functional and procedural languages do it? | Support for Lists within Arguments was requested by the WG. This would be a substantial change at this late stage. Refer to WG. Ensure it states in Blue Book that an Argument that is a list can only be of one type. | 3.3.5 Argument | N/A | N/A | N/A | Clarified | |||||||||||||||||
41 | 40 | WG Review Christoph Lenzen 09/5/23 | What is the use case for this [UNSUPPORTED] error message? Maybe specify the use cases of the different errors | The meaning of the errors, and effectively their use case, is explained in Section 7 on Errors. This error is returned if a message is received that contains an optional data structure not supported by the service provider. | 4.2.5.2 4.2.9.2 4.4.5.2 4.6.6.2 4.6.12.2 4.6.13.2 | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
42 | 41 | WG Review Christoph Lenzen 09/5/23 | We have an explanation for e.g. `Insert_Failed`. Should we have an explanation for all of these errors [REVOKE FAILED] in the same place in the errors subchapters? | There is an explanation for all MPS Error Codes in Chapter 5 "Errors" | 4.4.6.2 | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
43 | 42 | WG Review Christoph Lenzen 09/5/23 | [ACTIVATE FAILED]. Explanation would be nice | See #40, 41. Explanation of Errors is given in the Errors Chapter 5. | 4.4.8.2 | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
44 | 43 | WG Review Christoph Lenzen 09/5/23 | deactivation could fail, too. Should we add a `DEACTIVATE_FAILED` error? | I don't think it can - the text explains what should be done if execution has started. What other situation is there? | 4.4.9.2 | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
45 | 44 | WG Review Christoph Lenzen 09/5/23 | do we need an `ACTIVATE_FAILED`? | I don't think so - this is Activation of a Sub-plan, which is essentially a flag used to decide on whether individual activities in the plan should be started. Not sure how this operation itself can fail to Activate (set that flag). WG: Possible use case where the provider is talking to Spacecraft behind the scenes so could fail. Introduce Error codes suggested. | 4.4.12.2 5 | N/A | N/A | N/A | Updated | |||||||||||||||||
46 | 45 | WG Review Christoph Lenzen 09/5/23 | do we need a `DEACTIVATE_FAILED`? | I don't think so - this is Deactivation of a Sub-plan, which is essentially a flag used to decide on whether individual activities in the plan should be started. Not sure how this operation itself can fail to unset that flag. WG: Possible use case where the provider is talking to Spacecraft behind the scenes so could fail. Introduce Error codes suggested. | 4.4.13.2 5 | N/A | N/A | N/A | Updated | |||||||||||||||||
47 | 46 | WG Review Christoph Lenzen 09/5/23 | We should add the following: `It is up to the planning system, how to manage concurrent access to the plan, in particular how to prevent or manage the case that the planRef specified in the insertActivity is not the one of the currently active plan.` Also applies to insertEvent, DeleteActivity, DeleteEvent, UpdateActivity, UpdateEvent, UpdateResource, UpdateResourceProfile | OK in principle - but not sure that the second part of the comment is relevant. The Insertion should be to the referenced Plan, whether or not it is active. | 4.6.6.1 4.6.7.1 4.6.8.1 4.6.9.1 4.6.10.1 4.6.11.1 4.6.12.1 4.6.13.1 | N/A | N/A | N/A | Updated | Did not include from "in particular …" | ||||||||||||||||
48 | 47 | WG Review Christoph Lenzen 09/5/23 | Do we need to demand a special structure? We'd prefer this content to be whatever you need. [INVALID ERROR - Extra Info] [UNSUPPORTED ERROR - Extra Info] | This was the position of the WG after an extended discussion. Personally, I think it would be much simpler to have a free format string. However, it would not be possible to write standard code to highlight where in a message the problem is. | 5 | N/A | N/A | N/A | Open | No change - but consider issue during period of Agency Review. | ||||||||||||||||
49 | 48 | WG Review Olly Page 18/5/23 | Conceptually it's possible to reimplement serviceinteractions exactly as over the MAL using XML based transactions, but this isn't what we mean here. Rather we mean to implement a limited selection of major data structures to support effectively non-automates invocation of services, consisting of the three structures bullets. | Replace "such deployments" which leaves room for interpretation by "the exchange of information using the MPS Information Model structures" | 7.1 | N/A | N/A | N/A | Updated | |||||||||||||||||
50 | 49 | WG Review Maria Wörle 10/5/23 | Three cases of File Names being used with spaces - would be more consistent to omit the spaces. | Agreed | 7.5 | N/A | N/A | N/A | Updated | |||||||||||||||||
51 | 50 | WG Review Maria Wörle 10/5/23 | please use the same wording as for the service operations as specified in `operation identifiers`, e.g. - `List and Obtain Plans` should be `getPlanSummaries/getPlan/getPlanStatus` - `Apply Time Shift` should be `applyTimeShift` | Currently naming matches that in Table 12. There is no formal name for Capability Sets - only a number. Using the operation names seems more obscure to me. Add explanation that for services it is Service#.CapabilitySet#. For Capability Sets replace summary by list of actual Operation IDs. For File Formats add header row and F.1 etc. | Annexe A3 Table | N/A | N/A | N/A | Updated | |||||||||||||||||
52 | 51 | WG Review Maria Wörle 10/5/23 | NAV: is "Message" correct here? | Yes, but may also refer to NAV Working Group - to be updated | Annexe C | N/A | N/A | N/A | Updated | |||||||||||||||||
53 | 52 | WG Review Maria Wörle 10/5/23 | Should we add the SpaceOps Papers here? (at least the ones of 2021 and 2023) | I've not seen references to conference papers in any other CCSDS standard. I don't think we should include these. | Annexe D | N/A | N/A | N/A | Closed by Answer | |||||||||||||||||
54 | 53 | WG Review Maria Wörle 10/5/23 | Editorial comments | Accepted | Annexe E | N/A | N/A | N/A | Updated | |||||||||||||||||
55 | 54 | WG Review Maria Wörle 10/5/23 | Is the content here coming from the MAL? In this case, shouldn't we only add references and not explaining all that here? Otherwise, it seems quite complex and complicated. Sorryif I forgot, but did we ever talk about all this? similar here: is the notation derived from another standard (NAV?) or is it made up here for MPS only? | Does not come from MAL, but based on the need for a literal format within MPS Expressions. It was discussed and presented to the WG, but I don't believe it received much attention. It is the minimum required to be able to express a literal value for ObjectRef and Position/Direction types. As this is only in the context of an Expression, deployments are free to use their own Expression Language. | Annexe E.3 and E.4 | N/A | N/A | N/A | Editorial changes made to clarify that the Annex is optional. | Review to ensure that the Annexe does not suggest this is a compulsory part of the standard. | ||||||||||||||||
56 | 55 | CC review of XML email 26/6/23 | I was looking at the docx file and wondering why the Lists were all stripped away. After some time debugging, finally saw it, the true/false cannot start with a capital letter as it does not get parsed correctly. So, instead of: <mal:field name="aaa" nullable="False" comment="A comment"> <mal:type area="MyArea" list="False" name="ObjectRefList(MyType)"/> </mal:field> You should have: <mal:field name="aaa" nullable="false" comment="A comment"> <mal:type area="MyArea" list="false" name="ObjectRefList(MyType)"/> </mal:field> Same problem exists with the nullable field. | Capitalised "True" and "False" is the standard VBA output if a Boolean value is inserted into a string. Correct by using Lcase function. | N/A | N/A | N/A | Updated | Updated | |||||||||||||||||
57 | 56 | CC Comment in WG Meeting | Progress Pattern - difference between Update and Response messages Response should be empty and signal end of operation. | Change in all Progress pattern operations. Response message will be empty. Affects operations tables for Progress pattern operations and UML Sequence diagrams in the summary section of affected services that contain Progress pattern operations. Planning Request Service, Plan Distribution Service and Plan Information Management Service contain Progress pattern operations. | 4 multiple locations | Update Service Model UML Sequence diagrams | N/A | N/A | Updated | |||||||||||||||||
58 | ||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 |