I think that making the two elements optional inside the two sequences makes the model too loose. It allows a potential situation where you have an earlyTerminationProvision element without any child. I don't think this makes any business sense in this case. I think we should try to avoid that with the schema.
Let me try to explain the background for the structure I suggested in my last e-mail.
Guy, I think that what you are trying to accomplish here is something like:
<choice>
<choice>
mandatoryEarlyTermination
mandatoryEarlyTerminationDateTenor
<sequence>
mandatoryEarlyTermination
mandatoryEarlyTerminationDateTenor
</sequence>
</choice>
<choice>
optionalEarlyTermination
optionalEarlyTerminationParameters
<sequence>
optionalEarlyTermination
optionalEarlyTerminationParameters
</sequence>
<choice>
</choice>
So, in the first leg you have the option of choosing mandatoryEarlyTermination OR mandatoryEarlyTerminationDateTenor OR both. The same applies to the second leg.
Is my assumption correct? Is this the behavior which you are trying to accomplish?
If it is, this structure presents what is call "non-deterministic content model" because the processor, if it first encounters a child mandatoryEarlyTermination, will not know whether it should validate it against the first declaration of mandatoryEarlyTermination or the second declaration of mandatoryEarlyTermination (inside sequence), without looking ahead to see if there is also a child of mandatoryEarlyTerminationDateTenor. It may seem that it should not matter which mandatoryEarlyTermination declaration we are talking about; they both have the same type. However, they may have other different properties, such as default values, identity constraints, or annotations.
The following structure represents the same desired content model, in a deterministic way (it's the same I suggested in my first e-mail). It's nothing I invented, it's the solution presented in the Schema literature.
<choice>
<choice>
mandatoryEarlyTermination
<sequence>
mandatoryEarlyTerminationDateTenor
mandatoryEarlyTermination (minOccurs=”0”)
</sequence>
</choice>
<choice>
optionalEarlyTermination
<sequence>
optionalEarlyTermination
optionalEarlyTerminationParameters (minOccurs=”0”)
</sequence>
<choice>
</choice>
<choice>
<choice>
mandatoryEarlyTermination
<sequence>
mandatoryEarlyTerminationDateTenor
mandatoryEarlyTermination (minOccurs=”0”)
</sequence>
</choice>
<choice>
optionalEarlyTermination
<sequence>
optionalEarlyTermination
optionalEarlyTerminationParameters (minOccurs=”0”)
</sequence>
<choice>
</choice>
Sorry for my long explanation. Let me know if you have questions/comments.
Regards,
Marc
-----Original Message-----
From: Guy Gurden [mailto:guy.gurden@xxxxxxxxxxxxx]
Sent: October 13, 2004 9:21 AM
To: ird@xxxxxxxxxxxxxxxxxxxxx
Subject: FpML-IRD40 Updated Early Termination Provision proposal
Attached is an updated proposal following discussions at the last WG
meeting.
Marc G - The Schema I implemented here is slightly different to what you
circulated (see attached XSD Schema file for details)
Guy
-----Original Message-----
From: steven.lord@xxxxxxx [mailto:steven.lord@xxxxxxx]
Sent: Thursday, September 30, 2004 10:20 AM
To: ird@xxxxxxxxxxxxxxxxxxxxx
Subject: FpML-IRD40 FpML IRD WG - Minutes Thurs 30th
Minutes of WG meeting held on Thursday 30th September
Attendees:
Steven Lord
John Aldridge
Jeff Valentino (for Keri Jackson)
Guy Gurden
Bob Green
Marc Gratacos
RelativeSwap Proposal
There was general agreement that the proposal was ok. The changes that
Guy suggested via email should be incorporated.
Early Termination Provision Proposal
Guy talked the group through his proposal.
- If the optionalEarlyTerminationParameters element is included it is
assumed to be a mutual put
- Guy had tried to get a structure that would ensure that the mandatory
elements could not be included in a document with the optional ones.
ACTION: Marc to look at possible ways of achieving this
- There was agreement that this structure covered the use case that
prompted it - namely Broker Confirmations
- There was some discussion around whether these additional parameters
combined with the existing elements would be sufficient for
confirmations that include this parameterised view.
ACTION: Bob to look at how confirmation examples will fit into this
structure.
Bond Reference Proposal
Bob talked the group through his proposal. It was clarified that these
parameters were included for two purposes:
1. They indicated that the swap transaction was contingent on this bond
issue being completed
2. If the swap parameters differed from the bond then the bond would
take precedence.
There was alot of discussion around where this element should be placed
- there was agreement on the usefulness of including it. The agreement
was that it should be placed on the swap as this best reflected the
wording in a confirmation. It was agreed that a more generic structure
should be put in place to allow for over such contingencies to be
included.
ACTION: Bob to revamp proposal reflect the above and circulate to the
group for discussion at the next meeting.
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
---------------------------------------------------------------------
To unsubscribe, e-mail: ird-unsubscribe@xxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: ird-help@xxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
This is a commercial communication sent by SwapsWire Limited.
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version.
Please contact info@xxxxxxxxxxxxx if you no longer wish to receive
commercial communications from us, identifying the email addresses
to which you no longer wish commercial emails to be sent.