FpML Issues Tracker
closed
Minor
Always
Schema
SteveTurner
mgratacos
Summary
In confirmation view the Events.model has an additionalEvent element defined as
This in turn is defined as:
Is this meant to be a sustitution point? None of the other 'Events' are built from any sort of abstract event model.
Notes:
mgratacos
09/07/11 11:02 am
The html documentation says “The additionalEvent element is an extension point to customize FpML and add additional events.” But this annotation hasn’t been added to the schema as it should be. We’ll add it to the schema annotations.
The Working Group discussed this when the Events.model was introduced. Events are not built from an abstract model because there isn’t common content between the different events and the value is minimal. Also forcing to extend them from a single empty type was limiting any further derivation within each event that may be needed in the future.
Thanks,
Marc
SteveTurner
09/07/11 2:28 pm
Marc, I think there needs to be an abstract substitution group assigned additionalEvent too – otherwise how can the extension actually be used?
mgratacos
09/07/11 3:18 pm
Steve,
The additionalEvent global element is abstract. It should work as it is. I am attaching an example of a simple extension of additionalEvent. The myEvent element substitutes additionalEvent and seems to work fine (validated with xerces).
Marc
SteveTurner
09/07/11 5:56 pm
Hi Marc, Thanks for the example. It is/was highly unusual to see an element without a type defined in FpML. Although the technique ‘works’ (in XMLSpy) – the 3.0 arch spec doesn’t really cover this case, vis “Substituting elements MUST be type compatible with the substituted element.”
Have the Architecture group verified this approach?
– It does not allow FpML to control, or add to the extension in any way.
– It is in-effect the equivalent of a #any.
mgratacos
09/08/11 8:38 am
I don’t think this is an issue and I don’t see much difference, for example, from extending a product using the FpML product substitution group. With the product subs. group you get the optional product id and product type but you have freedom to create a complete new content model for a product. In this case you don’t carry any optional elements but you have also the freedom to design the content model. The additionalEvent element could be of a type Empty but this doesn’t add any value to the content and as I said, it limits any potential type inheritance.
(All what I am saying was discussed with main members of the AWG).
SteveTurner
09/08/11 9:40 am
Hi Marc, Type inheritance can only be utilised if there is a base type from which to inherit/extend. Without that as you say there is complete freedom – some might say anarchy! This approach violates the normal modeling rule that everything has a type (class).
To us this seems like a very big departure from modeling conventions in FpML.
Why not
h_mcallister
09/27/11 2:37 pm
Hi Marc, I agree with Steve Turner, I think this is definitely an issue, and it should not be allowed to remain in its current form. I will be raising this at the next Coordination committee.
Apologies for coming late to this – I saw the original issue (and assumed it was unarguable) but not the subsequent exchange of comments.
andrew
09/27/11 4:12 pm
I don’t remember this being discussed by the AWG.
Having an untyped element (e.g. defaulting to xsd:any) in the schema will affect the ability of some tools, especially binding tools, to work with the schema although the schema itself is valid.
I think we should at the very least introduce an abstract and empty type for compatible events to derive from.
mgratacos
09/28/11 9:42 am
I think it was discussed within the Modelling Task Force by some of the members of the AWG but I may be confused…it was a long time ago. All, I get your point that it is probably better to enforce at least the use of Schema for the extensions rather than defaulting it to xsd:any.
I’ve added an AdditionalEvent abstract complex type:
…