| org.tmforum.mtosi.message.InventoryRetrievalRequest | Line |
|---|
| The documentation says that ACTIVITY_NAME is supposed to be the "operation" name in the WSDL so this is taken from the portType section | 46 |
| If we are using a document/literal SOAP envelope, then why do we need MSG_NAME here? | 47 |
| org.tmforum.mtosi.message.MTOSIMessage | Line |
|---|
| make a property | 49 |
| Now that we use a SOAP envelope and the different name spaces, should we simply refer to the header by Header in the proper name space? No need to call it MTOSIHDR. (Francesco) | 82 |
| org.tmforum.mtosi.message.header.ActivityStatus | Line |
|---|
| ActivityStatus "WARNING" of what? | 44 |
| org.tmforum.mtosi.message.header.CommunicationPattern | Line |
|---|
| Why are the allowed values for CommunicationPattern in mixed case? | 42 |
| Is CommunicationPattern intended to indicate directions to the implementation of the service, or indications of the type of the request? | 43 |
| org.tmforum.mtosi.message.header.CommunicationStyle | Line |
|---|
| RPC makes no sense for CommunicationStyle as an RPC is a syntactic construct. What effect is this supposed to have? | 42 |
| Where do we indicate the MEP when we are using CommunicationStyle? | 43 |
| org.tmforum.mtosi.message.header.MessageHeader | Line |
|---|
| MessageHeader should be derived from header.xml, but there is only one header.xml and different mandatory and optional fields for different header types. | 40 |
| Should we consider making some of the header element extensible (e.g. qualifiable and extensible for Domain, activityStatus) (Francesco) | 42 |
| senderURI should be the names of topics or queues, not the "JNDI name for JMS transport" | 51 |
| How is security used? | 62 |
| How is securityType used? | 64 |
| If priority is optional, then why is there a default value? | 66 |
| Figure out to create a set of XML files such that we can read and substitute to get header fields | 96 |
| org.tmforum.mtosi.message.header.NotificationHeader | Line |
|---|
| NotificationHeader should be derived from header.xml, but there is only one header.xml and different mandatory and optional fields for different header types. | 40 |
| org.tmforum.mtosi.message.header.RequestHeader | Line |
|---|
| RequestHeader should be derived from header.xml, but there is only one header.xml and different mandatory and optional fields for different header types. | 40 |
| Figure out to create a set of XML files such that we can read and substitute to get header fields | 54 |
| org.tmforum.mtosi.message.header.RequestResponseHeader | Line |
|---|
| The RequestResponseHeader should be derived from header.xml, but there is only ne header.xml and different mandatory and optional fields for different header types. | 40 |
| This information, NO_COMPRESSION, is not in the table, it is on page 9 of SD2-2. | 45 |
| This information, NO_PACKING, is not in the table, it is on page 9 of SD2-2. | 46 |
| Since 1.0 only supports MSG, this is effectively mandatory always | 49 |
| SD2-2 page 9 says that BULK_RESPONSE is what the value should be for requests and response messages. Is that right? | 54 |
| Figure out to create a set of XML files such that we can read and substitute to get header fields | 59 |
| Since 1.0 only supports MSG, this is effectively mandatory always | 72 |
| org.tmforum.mtosi.message.header.ResponseHeader | Line |
|---|
| ResponseHeader should be derived from header.xml, but there is only one header.xml and different mandatory and optional fields for different header types. | 40 |
| Figure out to create a set of XML files such that we can read and substitute to create the header fields | 57 |
| Should we relax the order in the Header as we do in the other XSDs? (Francesco) | 58 |
