FpML Issues Tracker
closed
Crash
Always
Architecture
Admin
mgratacos
Summary
________________________________________ From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-comments-request@w3.org] On Behalf Of Jonathan Marsh Sent: 20 October 2006 21:57 To: matthew.d.rawlings@jpmchase.com Cc: ylafon@w3.org; Steve Ross-Talbot; stabet@ruleml.org; public-ws-desc-comments@w3.org Subject: RE: XML Schema requires a type in addition to name to identify an element
Thanks for your comment. The WS Description Working Group tracked this issue as a CR078 [1].
The Working Group, in part because of the late stages of development were in, was unable to reach consensus to add functionality to address your scenario. We note a few workarounds, some more attractive than others, which you might consider in addressing your scenario 1) Use element=#any. This reduces the descriptiveness completely, which is at odds with the desire to describe a specific FpML structure. 2) Use element=fmpl:FpML. This allows only FpML documents, but doesnt further constrain the precise structure of FpML. This isnt unreasonable, as it doesnt circumvent the kind of flexibility for which the schema was originally designed, yet it doesnt support the use case of specifying a subset of the possible structures that is intended for the operation. 3) Wrap the FpML types in a set of wrapper elements (unfortunately not named FpML), so the content of the element can be precisely determined. Unfortunately this morphs the root element name on the wire, so the messages conform to the wrapped schema, but not directly to the unwrapped FpML schema. 4) Use an extension of your own invention to specify further validation constraints (such as the allowed values of xsi:type). This is slightly more machine-readable than specifying the further constraints in text. 5) Consider an extension framework, such as SAWSDL [2], to encode higher level semantics and constraints upon the message exchanges.
Unless you let us know otherwise by the end of October, we will assume you agree with the resolution of this issue.
[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR078 [2] http://lists.w3.org/Archives/Public/public-ws-semann-comments/
Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
Notes:
matthew
10/20/06 6:42 pm
This is an issue we need to tackle at the AWG.
matthew
10/30/06 7:00 am
Marc – has there been any progress on this issue?
mgratacos
10/30/06 7:08 am
The AWG discussed this issue again on the 2006/10/27 meeting. Andrew Jacobs put together some schemas that create a root element for each message type. These elements are contained in a separate namespace from FpML. There is no agreement on this:
– Members expressed that these root elements should be placed within the FpML namespace.
– Introducing these elements would imply removing the current type substitution mechanism at the root element. Otherwise we would have two ways to do the same thing.
– This is probably a 5.0 change.
– The question is when to introduce 5.0.
matthew
04/04/07 11:43 am
Still being debated hotly.
mgratacos
06/25/07 5:25 pm
Standards Committee agreed on June 22, 2007 to have distinct root element for each message type in FpML 5.0.
mgratacos
07/05/07 3:31 pm
Root elements have been implemented in the 5.0 branch.