The paper Andrew put together for the Standards Committee (thank you, by
the way, Andrew) was based on a proposal paper I had put out towards the
end of 2007. In that paper I did point out that there would be risks
to the canonical approach from the perspective of the receiver and that
a versioned URI could still be used for added specificity if the sender
knew the intended version. My original proposal was simply to have
a documented use for the canonical URI (and perhaps a canonical URL for
the latest xml file) on schemes and to potentially decouple them from publications
of the core standard.
As for the non-versioned URI's being
preferable on certain schemes - this was mainly due to the fact that some
schemes are driven to change often by the market and are usually being
added to (brand new centers being added) rather than being modified (existing
centers being renamed/removed). By using the canonical URI on schemes
like business center or contractual supplement, messages tend to be forwards/backwards
compatible as FpML adds values to the scheme without having to reference
a new version of it in instance documents.
As mentioned before there are advantages
and disadvantages to this approach but I think you put it well by stating
"it's preferable to provide less detailed but correct information,
rather than more detailed but perhaps incorrect information". I
think by keeping the concept of a versioned URI in tact, the use of a canonical
URI becomes an additional tool for implementers to leverage schemes effectively
in FpML.
Regards,
Henri Pegeron
------------------------------------------------------------
The Depository Trust & Clearing Corporation
DTCC Deriv/SERV : Business Analysis & Design
55 Water Street - New York, NY 10041
Phone: + 1 (212) 855 1682
Fax: + 1 (212) 855 1020
"Daniel Dui"
<daniel.dui@xxxxxxxxx> Sent by: awg@xxxxxxxx
05/22/2008 10:53 AM
Please respond to
awg@xxxxxxxx
To
awg@xxxxxxxx
cc
Subject
FpML-AWG More on Canonical Scheme URIs
I had some comments about the usage of versioned/canonical
URIs. These
are my thoughts:
I think that the guiding principle should be that the sender should
provide information that is as detailed as possible, but that it's
preferable to provide less detailed but correct information, rather
than more detailed but perhaps incorrect information.
Implication for the sender of the message:
An FpML message should contain a versioned scheme URI when the sender
is certain of version of the code list to which the code belongs. In
practice this means that the sender performs scheme validation before
sending a message.
An FpML message should contain a non- versioned scheme URI when…
a) The sender can't be certain of the version of the code list to
which the code belongs. This is usually the case of the sender does
not perform scheme validation before sending a message.
b) The sender is deliberately using codes that don't belong to any
version of the currently standardised code lists.
Implications for the receiver of the message:
The receiver of a message that contains a versioned URI should
preferably interpret the code against the appropriate version of the
code list. Alternatively it may interpret the code against the most
recent version of the code list that it is aware of.
The receiver of a message that contains a non-versioned URI should
interpret the code against the most recent version of the code list
that it is aware of.
I am not sure I agree with this paragraph in the final "In Summary"
section of the document.
"There are a small number of schemes for which a canonical URI would
appear to be a better choice generally (e.g. business centers, etc.)
than the current versioned one."
Why would it be preferable to use a non-versioned URI for business centers?
-daniel
-------------------------------------------------------------------------------
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
________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.