Closed mjpt777 closed 5 years ago
@mjpt777 has this issue been resolved in the Real Logic implementation, or do we need to update the XML schema? If so, a PR would be helpful.
We have a work around in the Real Logic implementation. The SBE schema needs to be fixed for a more general solution. A better approach is for those running the spec to have tests that serve as illustration and a means to validate what is said in the spec is possible.
Here is how this can be fixed.
https://stackoverflow.com/questions/5843364/require-allow-xmlbase-attribute-in-xml-schema
BASE allows authors to explicitly specify a document's base URI for the purpose of resolving relative URIs in links to external images, applets, form-processing programs, style sheets, and so on.
Evidently, this issue with XInclude and xml:base has a long history of controversy. One issue with the solution presented in stackoverflow is that you have to include the following attribute to each XML type that you want eligible for inclusion.
<xs:attribute ref="xml:base" />
With suggested schema changes, I've created a valid example that imports a <types>
element. (I also added description
attribute to that element so you can document what each set of types is for.)
My question to the group is: should we also support inclusion of common message templates into a message schema? It seems reasonable to me. Element <message>
is of XML type blockType
, so if I add the xml:base
attribute to blockType
, then it will also apply to repeating groups since groupType
extends it.
Offering an alternative to the solution suggested above: One flaw in the original schema design is that <type>
elements are contained by <types>
but there is no equivalent container for <message>
elements. If we add xml:base to a new <messages>
container element, then you could use XInclude for groups of commonly used message templates across message schemas. Then would be no need to alter blockType.
It did seem a bit inconsistent that version 1.0 had <types>
but not <messages>
. We learn these things after an implementation is done and people try to use it. It would make sense to have a <messages>
container in 2.0.
If include of messages is supported then it would be really important to have an optional package
attribute on types and messages. We also need to be careful with namespaces as I had a lot of wasted time getting an implementation parse well with and without namespaces.
For the following to be correct the SBE XSD schema needs to allow for the xml:base attribute.
https://github.com/FIXTradingCommunity/fix-simple-binary-encoding/blob/master/v1-0-STANDARD/doc/04MessageSchema.md#importing-encodings
https://www.w3.org/TR/xinclude/#base