Skip to content

[unified2orchestra] Add missing inlined attribute to appInfo for FIXML #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kleihan opened this issue Mar 9, 2022 · 14 comments
Open
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@kleihan
Copy link
Member

kleihan commented Mar 9, 2022

FIXML schema has a few inlined components:

  • InstrumentLeg
  • UnderlyingInstrument
  • InstrumentScope

Unified identifies them with the attribute inlined="1". This information is not transformed to Orchestra but needed for orchestra2unified to ensure backward compatibility.

The existing appInfo element with purpose="FIXML" is currently only used for the notReqXML attribute. Both FIXML related attributes should be in a single appInfo element with the notReqXML="1" and inlined="1". Both have a default value 0 and should be absent unless the value needs to be 1.

@jimnup
Copy link

jimnup commented Mar 10, 2022

The AppInfo element itself should not be extended with application specific attributes. Instead, it is envisioned that XML specific to the Application would be added as child elements (which of course can have attributes). The XML child elements could be defined with an optional XML Schema.

<AppInfo purpose="FIXMLencoding">
<FIXMLencoding inline="1"/>
</AppInfo>

<AppInfo purpose="FIXMLencoding">
<FIXMLencoding notReqXML="1"/>
</AppInfo>

@kleihan
Copy link
Member Author

kleihan commented Mar 10, 2022

So you are saying that appInfo should not need to be parsed by orchestra2unified but simply contain an XML snippet, e.g. notReqXML="1" that is added by orchestra2unified to the output element it creates?

Could the entire XML snippet be part of a single appInfo element?

<fixr:appInfo purpose="FIXMLencoding">
    <FIXMLencoding inline="1" notReqXML="1"/>
</fixr:appInfo>

Purpose and element name is identical which seems redundant. If we omit the purpose (I believe it is optional) then we could have a single appInfo element for multiple encodings and their XML snippets.

<fixr:appInfo>
    <FIXMLencoding inline="1" notReqXML="1"/>
    <SBEencoding semanticType="int"/>
</fixr:appInfo>

This could be the path to establishing Orchestra as the only schema in FIX with the capability of creating "legacy" schemas for FIXML and SBE for backward compatibility. Thoughts?

@jimnup
Copy link

jimnup commented Mar 10, 2022

The purpose attribute is important - as it identifies what application the information pertains to. It is also benefits UI builders and processors.
FIXMLencoding and SBEencoding are separate applications and should each have their own AppInfo section.

Your first example I believe is the most appropriate and you would have two AppInfos if needed for SBE and FIXML.

<fixr:appInfo purpose="FIXMLencoding">
    <FIXMLencoding inline="1" notReqXML="1"/>
</fixr:appInfo>

<fixr:appInfo purpose="SBEencoding">
    <SBEencoding semanticType="int"/>
</fixr:appInfo>

@jimnup
Copy link

jimnup commented Mar 10, 2022

Although the SBE example - is just an example of course. I think Don has built in datatype mapping into Orchestra. Is that correct Don?

@kleihan
Copy link
Member Author

kleihan commented Mar 10, 2022

Understood that the applications are FIXML and SBE and need separate appInfo elements with their own purpose. Syntactically, I would prefer to see less redundancy, i.e. just have encoding as element that can be used for multiple applications. Would you agree, Jim?

<fixr:appInfo purpose="FIXML">
    <encoding inline="1" notReqXML="1"/>
</fixr:appInfo>

<fixr:appInfo purpose="SBE">
    <encoding semanticType="int"/>
</fixr:appInfo>

@jimnup
Copy link

jimnup commented Mar 10, 2022 via email

@kleihan
Copy link
Member Author

kleihan commented Mar 10, 2022

Agree, that allows to have separate attributes. I would still keep the purpose more generic to support more than one element. Or is that not possible? I believe the schema says unbounded.

<fixr:appInfo purpose="FIXML">
    <FIXMLencoding inline="1" notReqXML="1"/>
    <secondElement abc="Y"/>
</fixr:appInfo>

<fixr:appInfo purpose="SBE">
    <SBEencoding xyz="1"/>
</fixr:appInfo>

@jimnup
Copy link

jimnup commented Mar 10, 2022 via email

@jimnup
Copy link

jimnup commented Mar 10, 2022 via email

@donmendelson
Copy link
Member

donmendelson commented Mar 11, 2022

Proposed schema

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:element name="FIXMLencoding" type="FIXMLencodingType">
		<xs:annotation>
			<xs:documentation>Attributes for FIXML generator</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:complexType name="FIXMLencodingType">
		<xs:attribute name="inlined" type="xs:boolean" default="0">
			<xs:annotation>
				<xs:documentation>If true, a component is inlined in a containing message or component</xs:documentation>
			</xs:annotation>
		</xs:attribute>
		<xs:attribute name="notReqXML" type="xs:boolean" default="0">
			<xs:annotation>
				<xs:documentation>If true, an element is ignored by FIXML generator</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
</xs:schema>

@kleihan
Copy link
Member Author

kleihan commented Mar 11, 2022

Looks good, changed the attribute from "inline" to "inlined" (see Unified schema).

@donmendelson
Copy link
Member

I am able to write appinfo element using the new schema, for example:

            <fixr:componentRef added="FIX.4.4" updated="FIX.5.0SP2" updatedEP="192" id="1021">
                <fixr:annotation>
                    <fixr:appinfo purpose="FIXML">
                        <fixml:FIXMLencodingType inlined="1" />
                    </fixr:appinfo>
                    <fixr:documentation>
                        Required if NoUnderlyings(711) &gt; 0.</fixr:documentation>
                </fixr:annotation>
            </fixr:componentRef>

However, to make it work, I had to disable validation in the Python xmlschema library. The output will need to be validated externally.

@kleihan
Copy link
Member Author

kleihan commented Mar 11, 2022

Having the namespace "fixml:" as well as the element prefix "FIXML" now seems redundant again. Would SBE have its own namespace? Or do the element names still need to be unique as well?

                    <fixr:appinfo purpose="SBE">
                        <sbe:encodingType ... />
                    </fixr:appinfo>

@donmendelson
Copy link
Member

A namespace prefix is not a permanent name; it's scope is only the current file, and it can be anything so long as it's unique within the file. In this case, it is an alias for the URI http://fixprotocol.io/2022/orchestra/appinfo/fixml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants