[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FpML-VAL cd-26 unhandled case

To: <valwg@xxxxxxxx>
Subject: RE: FpML-VAL cd-26 unhandled case
From: "Andrew Jacobs" <andrew.jacobs@xxxxxxxxxxxxxx>
Date: Tue, 21 Apr 2009 20:39:04 +0100
Importance: Normal
In-reply-to: <A616F5F4EF9BA740B76648E78A8A83E0F0B2EE14@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: valwg@xxxxxxxx
Sender: valwg@xxxxxxxx
Thread-index: AcnCYGBib95zhZP6RC6eriBHz9ejpwAHC10AAA7+vyA=

"dayType is of type PeriodEnum. Why is PeriodEnum a restriction of xs:token
rather than xs:NMTOKEN? Shouldn't all the enums be restrictions on
xs:NMTOKEN"

No. NMTOKEN is provided for backwards compatibity with XML DTD grammars.

[Definition:]   NMTOKEN represents the NMTOKEN attribute type from [XML 1.0
(Second Edition)]. The ·value space· of NMTOKEN is the set of tokens that
·match· the Nmtoken production in [XML 1.0 (Second Edition)]. The ·lexical
space· of NMTOKEN is the set of strings that ·match· the Nmtoken production
in [XML 1.0 (Second Edition)]. The ·base type· of NMTOKEN is token.

For compatibility (see Terminology (§1.4)) NMTOKEN should be used only on
attributes.

Thanks

Andrew Jacobs
Director, HandCoded Consulting Ltd.
Director, HandCoded Software Ltd.
Mob: +44 (0)7710 304239

-----Original Message-----
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On Behalf Of Matthew D Rawlings
Sent: 21 April 2009 14:11
To: valwg@xxxxxxxx
Subject: RE: FpML-VAL cd-26 unhandled case

I concur with the comments.

We could add a guard to ird-14 to restrict it to effectiveDate, but we could
alternatively add support for relativeEffectiveDate. The only problem with
relativeEffectiveDate is that we cannot support evaluating
relativeEffectiveDate when relativeEffectiveDate/dayType exists because we
need calendars to evaluate dayType.

//dayType is of type PeriodEnum. Why is PeriodEnum a restriction of xs:token
rather than xs:NMTOKEN? Shouldn't all the enums be restrictions on
xs:NMTOKEN?

Matthew +44 7917 596 827

-----Original Message-----
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On Behalf Of Christian Nentwich
Sent: 21 April 2009 10:06
To: valwg@xxxxxxxx
Subject: Re: FpML-VAL cd-26 unhandled case

Matthew,

if the rules need to be complete with respect to optionality, you'll 
find quite a few others where this is not the case - because they were 
not originally written with that in mind.

For example ird-14:

terminationDate/unadjustedDate gt effectiveDate/unadjustedDate

A swap might have a relativeEffectiveDate instead of effectiveDate... 
Anybody got a fine tooth comb handy?

Christian

Matthew D Rawlings wrote:
>
> Dear VWG -
>
> cd-26 does not handle the effectiveDate being optional.
>
> cd-26 today is:
> "
> Context: CreditDefaultSwap (complex type) 
> [exists(feeLeg/singlePayment/adjustablePaymentDate)]
> feeLeg/singlePayment/adjustablePaymentDate gt
> generalTerms/effectiveDate/unadjustedDate
> "
>
> There is a guard on paymentDate, there should also be a guard on
> effectiveDate. I propose the new rule be:
> "
> Context: CreditDefaultSwap (complex type)
>
[exists(feeLeg/singlePayment/adjustablePaymentDate)][exists(generalTerms/eff
ectiveDate)]
> feeLeg/singlePayment/adjustablePaymentDate gt 
> generalTerms/effectiveDate/unadjustedDate
> "
>
> I do not know the scenarios under which generalTerms/effectiveDate may
> be optional. The schema fails to document what it means when the field 
> is not present. We should also get the schema documentation fixed up 
> to state what it means when the element is not present.
>
> This is logged as issue: http://www.fpml.org/issues/view.php?id=926
>
> Matthew +44 7917 596 827
>
> ----------------------------------------------------------------------
> --
>
> This communication is for informational purposes only. It is not
> intended as an offer or solicitation for the purchase or sale of any 
> financial instrument or as an official confirmation of any 
> transaction. All market prices, data and other information are not 
> warranted as to completeness or accuracy and are subject to change 
> without notice. Any comments or statements made herein do not 
> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries 
> and affiliates. This transmission may contain information that is 
> privileged, confidential, legally privileged, and/or exempt from 
> disclosure under applicable law. If you are not the intended 
> recipient, you are hereby notified that any disclosure, copying, 
> distribution, or use of the information contained herein (including 
> any reliance thereon) is STRICTLY PROHIBITED. Although this 
> transmission and any attachments are believed to be free of any virus 
> or other defect that might affect any computer system into which it is 
> received and opened, it is the responsibility of the recipient to 
> ensure that it is virus free and no responsibility is accepted by 
> JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, 
> for any loss or damage arising in any way from its use. If you 
> received this transmission in error, please immediately contact the 
> sender and destroy the material in its entirety, whether in electronic 
> or hard copy format. Thank you. Please refer to 
> http://www.jpmorgan.com/pages/disclosures for disclosures relating to 
> European legal entities.
>

----------------------------------------------------------------------------
---
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

----------------------------------------------------------------------------
---
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html

-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html

References:
- RE: FpML-VAL cd-26 unhandled case
  - From: Matthew D Rawlings

Prev by Date: RE: FpML-VAL cd-26 unhandled case
Next by Date: FpML-VAL 0000928: shared-10 path doesn't exist - FpML - Financial products Markup Language
Previous by thread: RE: FpML-VAL cd-26 unhandled case
Next by thread: FpML-VAL 0000928: shared-10 path doesn't exist - FpML - Financial products Markup Language
Index(es):
- Date
- Thread