|
Unless I hear otherwise, I’ll
recommend to change the schema to make trade valuation item contain a choice
between 1 or more partyTradeIdentifiers and 1 trade. I think this should
be done in 4.3, given that 4.2 is in trial… Comments welcome. From: prwg@xxxxxxxx
[mailto:prwg@xxxxxxxx] On Behalf Of Brian
Lynn Sorry not to reply earlier … I didn’t originally develop this
structure, and I don’t have any great answers for you. On the face of it, there seems to need to
be only one trade per trade valuation item. There could be multiple
partyTradeIdentifiers identifying the same trade. Does anyone have any objection to changing
the content model to eliminate the possibility of including 1) more than one trade per trade valuation item, and 2) both a trade and a partyTradeIdentifier? If not, we need to think about when/how to
implement, since this has been in since 4.1 and removing this flexibility is
arguably not backwards compatible …. We could declare it an error but
theoretically it should be approved by the Stds Committee. - Brian From: prwg@xxxxxxxx
[mailto:prwg@xxxxxxxx] On Behalf Of Marc
Gratacos Brian, Any thoughts on this? See below. Thanks, Marc From: prwg@xxxxxxxx
[mailto:prwg@xxxxxxxx] On Behalf Of Marc
Gratacos Brian, Maybe I am missing something but I am looking at the content
of TradeValuationItem and I don't understand its content model. Why do we have
trade with maxOccurs="unbounded"? Shouldn't we have a single trade
element only? In addition, shouldn't we have a choice between
partyTradeIdentifier and trade? <xsd:complexType name="TradeValuationItem"> From:
prwg@xxxxxxxx on behalf of Brian Lynn The issue says that the TradeValuationItem
should probably have only one partyTradeIdentifier, or there should be a rule
that if there is more than one partyTradeIdentifier, it should refer to the
same trade. The existing documentation on that item
says, “One or more trade identifiers needed to uniquely identify a
trade.” This implies that the multiple trade IDs are for the
same trade. I’m not sure if it’s possible to create a rule
that enforces this. Should we update the documentation on the
element to make this more explicit? - Brian From: prwg@xxxxxxxx
[mailto:prwg@xxxxxxxx] On Behalf Of Marc
Gratacos Brian, See question posted in the issues list: http://www.fpml.org/issues/view.php?id=204
Kind Regards, -Marc +13472846531 **************************************************************************************************************************
The information contained in either this email and, if applicable, the
attachment, are confidential and are intended only for the recipient. The
contents of either the email or the attachment may not be disclosed or used by
anyone other than the addressee. If you are not the intended recipient(s), any
use, disclosure, copying, or distribution is prohibited and may be unlawful. If
you have received this communication in error, please notify us by e-mail at
isda@xxxxxxxx then delete the e-mail and all attachments and any copies
thereof. This communication is part of an ISDA process and is not intended for
unauthorized use or distribution.
************************************************************************************************************************** |