1 / 10

Architecture Working Group

Architecture Working Group. Andrew Jacobs. Introduction. The AWG has been examining two separate but related issues: Having the root node express the message type would make messaging easier to understand and the documents easier to process e.g. <requestTradeConfirmation/>

tansy
Download Presentation

Architecture Working Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecture Working Group Andrew Jacobs

  2. Introduction • The AWG has been examining two separate but related issues: • Having the root node express the message type would make messaging easier to understand and the documents easier to process • e.g. <requestTradeConfirmation/> • Using type substitution on the FpML element is incompatible with WSDL based WebServices

  3. Modelling Issues • Many XML design tools don’t show types that can be substituted • Looking at the FpML element shows an empty element • Have to find message types in a long list of complex types • XML binding tools have poor support type substitution • XML parsing and XSLT processors are fine • Note however: • Type substitution is currently also used in FpML for block trade identifiers. • It is used by a number of firms to introduce extended types into FpML documents

  4. The WSDL Problem • WSDL interfaces are defined in terms of elements • Type substitution within the element is not allowed • The W3C were queried and did not support a change to the WSDL specification to allow it.

  5. First Vote • Changing the root element was first voted on in January along with 3 other issues • Fewer options where considered than latest round • Some uncertainty around the options • Voting was tied • It was decided to look at the problem again, see what some other standards do, and re-vote • Brian Lynn asked to produce a paper

  6. WSDL - A Red Herring? • WSDL documents can contain their own schema definitions to create elements from imported types • Elements for method parameters can be created within the WSDL as needed. • e.g <xsd:element name=“someParam” type=“FpML:RequestTradeConfirmation”> • Using FpML types in WSDL interfaces ties it to a single specific version • Service providers would want probably support several versions simultaneously • Possibly ‘string’ based to allow any XML to be passed

  7. (A) No change <FpML xsi:type=“messageType”> (B) New wrapper element containing FpML <messageType> <FpML>…</FpML></messageType> (C) Substitution group with FpML <FpML …> <messageType>…</messageType></FpML> (D) Message type as a value field <FpML> <transactionType>messageType </transactionType> …</FpML> (E) Root element name indicates message type <messageType version=“5.0”> …</messageType> Expanded Set of Options

  8. May Voting – 7 to 3 DTCC vote received after cut-off.

  9. Modifications to Rules of Operation • Currently doesn’t allow a change to: • The root element, or • FpML version attributes • Both need to changed • To allow multiple root elements • Make version attribute more FpML specific • e.g. fpmlVersion • Requires Standards committee approval.

  10. Related Work • Changes will require updates to: • Architecture specification • Messaging specification • Schemas • Examples & test cases • Other 5.0 features are scheduled for the summer but implementation may take longer • Delay 5.0 or release later as 6.0? • Can’t be 5.1 as changes are not backwards compatible

More Related