I've updated this proposal based on input from today's BPWG meeting. (See attached). Some of the changes slightly adjust existing PRWG 4.1 or 4.2 definitions, but I believe that the changes are small enough to be considered minor errata. However, there is one larger issue that I've identified below. I've made the following changes: 1) As decided at the BPWG meeting, I changed the content model of "RequestPositionReport" and "RequestPortfolio" to provide a choice between a)a data set name or portfolio (depending on the message) and b) the requested positions. This eliminates a great deal of optionality in the messages. Since these types are new for 4.3, there is no issue with making these changes. See the attached .JPGs for a visual representation of the resulting structure. 2) I've changed the definitions of "dataSetName" in 2 places to "xsd:normalizedString" from "xsd:string". This slightly changes the definition of the PositionReport from FpML 4.2. 3) I've changed the definition of "Valuation" to make the cardinality of "quote" to be 1..unbounded (it was 0..unbounded). I believe that the original definition was in error as the documentation of the element says that there should be "one or more" quotes, and I can't think of a case where it makes sense to have 0 quote elements here. Also, none of the existing examples appear to use 0 quotes. This slightly changes the definition of several types from FpML 4.1 and 4.2, but I believe corrects an error. 4) I've moved the definition of the "RequestedPositions" type to the valuation subschema to allow it to be used by both the reporting and reconciliation subschemas, and made a few internal changes to that type with no effect on the content model to resolve dependency issues. PRWG members, please let me know if you have any concerns about any of the above changes to existing definitions. BPWG and PRWG members, please let me know if you have any feedback on the above messages. I identified one additional concern while testing the latest changes: The latest Position definition makes the positionId mandatory. This causes the existing 4.2 PRWG position report examples, which do not include the positionId, to fail schema validation. We can certainly update the examples to include position IDs, but it occurred to me that if we make this change in FpML 4.3 only, then 4.3 will not be backwardly compatible with 4.2 in the area of positions. I don't suppose anyone is really that concerned about this, but I do think that it violates the change control guidelines, so we should address this somehow. It seems to me that we have a few options for resolving this, e.g.: - make position ID optional in the position report, and restrict the type to make it mandatory in the define portfolio message. - add the positionId to Position in the FpML 4.2 trial recommendation. - just update the example and go to the Standards Committee for approval of the change. (We might want to document somewhere in 4.2 that the change is planned...) Please let me know if you have any comments or suggestions on any of this. Best regards, Brian Lynn, CTO Global Electronic Markets, http://global-emarkets.com High-speed FpML matching, reconciliation, and validation: http://fpml-mediator.com
Attachment:
QueryPortfolio.jpg
Description: JPEG image
Attachment:
RequestPortfolio.jpg
Description: JPEG image
Attachment:
RequestPositionReport.jpg
Description: JPEG image
Attachment:
fpml-valuation-4-2.xsd
Description: Binary data
Attachment:
fpml-reconciliation-4-2.xsd
Description: Binary data
Attachment:
fpml-reporting-4-2.xsd
Description: Binary data
