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:
- 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.
- Changing
the meaning of an element without changing the schema. For example if
"sender" becomes an application instead of an organization.
- 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.