[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: RE: FpML-AWG AWG Teleconference 29-May-08
I agree that we should debate in the AWG whether to tighten the guidelines.
Cheers, Tony.
--
Sent from my mobile phone.
Anthony B. Coates
abcoates@xxxxxxxxxxx
+44 (79) 0543 9026
-original message-
Subject: RE: FW: RE: FpML-AWG AWG Teleconference 29-May-08
From: matthew.d.rawlings@xxxxxxxxxxxx
Date: 30/05/2008 12:17
I agree we should tighten the guidelines following a debate in the AWG.
Matthew Rawlings
+44 7917 596 827
"Brian Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Sent by: awg@xxxxxxxx
29/05/2008 18:37
Please respond to
awg@xxxxxxxx
To
<awg@xxxxxxxx>
cc
Subject
RE: FW: RE: FpML-AWG AWG Teleconference 29-May-08
Matthew –
On your point #1, it’s possible that we should tighten the guidelines.
However, we’ve not previously assumed that we need to support schema-aware
XPath expressions; if so, we would certainly need more rules on the ways
we can evolve types. This is something that the group needs to decide,
but I don’t think it relates to the proposed change in the namespace, as
it is the elements in the instance documents that are validated against a
schema, not the types that may have been assumed when creating them.
The example you given in #1 below was a change to an element name, not a
type name, I believe. I think it happened prior to the introduction of
the guidelines. Even if not, we did intentionally break the guidelines
(following the exception process) to allow equities to reorganize their
model for FpML 4.1. This type of exception would presumably no longer be
possible if we adopt the proposed namespace change, so we probably need to
remove this option from the guidelines.
My point wasn’t that the guidelines are necessarily sufficient, just that
the specific example problem cited is one that we’ve already anticipated.
Doubtless we’ll find some that aren’t.
On your point #2, this arguably is covered by the high level prohibition
on invalidating existing instance documents, but perhaps we should add an
additional detailed guideline as you suggest. In practice I don’t think
we’ve ever done what you suggested is possible (changed the meaning of an
element without changing its name), but I guess there’s always a first
time.
On your point #3, I don’t understand your point at all in the context of
backward compatibility. Adding a new element that changes the
interpretation of an existing element only matters if the element is
present in the instance document. In other words, if an instance document
doesn’t contain the new element, the interpretation remains as before.
What is the problem with allowing these elements to appear in new minor
versions of the schema? (Why is this not backward compatible?) If you
want the new interpretation, you use the new structure, and if you don’t,
you don’t. As long as the old interpretation is still available in the
schema, we should be fine.
- Brian
From: awg@xxxxxxxx [mailto:awg@xxxxxxxx] On Behalf Of
matthew.d.rawlings@xxxxxxxxxxxx
Sent: Thursday, May 29, 2008 1:10 PM
To: AWG
Subject: Re: FW: RE: FpML-AWG AWG Teleconference 29-May-08
Brian -
The current FpML Change Control Guidelines are currently too loose for
this purpose. Changes can be made that are not backwards compatible, such
as:
1. Making a change to the schema that breaks schema-aware XPath. A
good example is that renaming a complex type would break a FpML Validation
Rule that used that type as a context. For example when
equityBermudaExercise changed from equityBermudanExercise this was not
backwards compatible for eqd-6, eqd-7, eqd-8, eqd-9, and eqd-10.
2. Changing the meaning of an element without changing the schema.
For example if "sender" becomes an application instead of an organization.
3. Adding an element that changes the definition of an existing
element. For example adding tradeSide changed the interpretation of
/FpML/trade/capFloor/capFloorStream/payerPartyReference so that it may
point to a tradeSide rather than a party.
There are others I won't list, but these 3 represent examples of a
backwards incompatible change that was within the FpML Change Control
Guidelines. For fpmlVersion to work a much stricter definition of
backwards compatible is needed.
Matthew Rawlings
+44 7917 596 827
-original message-
Subject: RE: FpML-AWG AWG Teleconference 29-May-08
From: "Brian Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Date: 2008-05-29 15:40
This specific change is already prohibited within a single major version
by
the FpML Change Control Guidelines for backward compatibility reasons.
Similarly, we can't change the names of existing elements, remove required
elements, make optional elements mandatory, etc. These guidelines do
cause
some headaches but we've been working within them (more or less) for a
couple of years. A consequence is that when we add new elements we
usually
need to make them optional, or create a choice between the old and new
ways.
On each major version we can review and decide to make the new stuff
mandatory.
http://www.fpml.org/documents/standard/changeGuidelines.pdf
- Brian
From: awg@xxxxxxxx [mailto:awg@xxxxxxxx] On Behalf Of
mark.a.addison@xxxxxxxxxxxx
Sent: Thursday, May 29, 2008 10:19 AM
To: awg@xxxxxxxx
Subject: Re: FpML-AWG AWG Teleconference 29-May-08
I still have some concerns with respect to the proposed idea of dropping
minor version from the schema namespace.
As an example, it will not be possible to add a required element to any
new
minor version of the schema (a major version will be required.)
i.e. for backward compatibility reasons - because documents produced using
a
previous minor version could not possibly contain the field and would not
validate against the schema.
Is this going to be too limiting?
Regards,
Mark.
_____
Generally, this communication is for informational purposes only and 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. In
the event you are receiving the offering materials attached below related
to
your interest in hedge funds or private equity, this communication may be
intended as an offer or solicitation for the purchase or sale of such
fund(s). 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 UK
legal entities.
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 UK
legal entities.
-----------------------------------------
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 UK legal entities.
-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe awg youremail@address
To view archives: http://www.fpml.org/_wgmail/_awgmail/threads.html