Changing the Root Element

Download Report

Transcript Changing the Root Element

Changing the Root Element
Andrew Jacobs
AWG Chair
Introduction
• The AWG has be examining two separate
issues:
– Having the root node express the message type
would make messaging easier to understand
• e.g. <requestTradeConfirmation/>
– Using type substitution on the FpML element is
incompatible with WSDL based WebServices
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
• Type substitution is considered a ‘difficult’ feature
of XML schema
– “Business analysts don’t understand it”
– Some XML binding tools don’t understand it
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.
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.
Considered Options
•
(A) No change
–
•
•
(D) Message type as a value field
–
<FpML xsi:type=“messageType”>
(B) New wrapper element
containing FpML
–
<messageType>
<FpML>…</FpML>
</messageType>
•
(E) Root element name indicates
message type
–
•
(C) Substitution group with FpML
–
<FpML …>
<messageType>…</messageType>
</FpML>
<FpML>
<transactionType>messageType
</transactionType>
…
</FpML>
<messageType version=“5.0”>
…
</messageType>
Voting
• Vote in May found 6 to 4 in favour of
adopting new root element approach
– <requestTradeConfirmation/>
• Clear split between banks and vendors
– Banks in favour of the change
– Vendors preferred solutions that maintained
FpML root
Change 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.
Consequences
• Will require updates to:
–
–
–
–
–
Architecture specification
Messaging specification
Schema
Examples & test cases
Training course materials
• Would have to be a 5.0 (or 6.0) change