[unified2orchestra] Add missing inlined attribute to appInfo for FIXML

[kleihan]

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]

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]

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]

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]

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]

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]

I would not use the same element name in this case - I would consider using different element names. That way you can create a schema specific to to each element - FIXML encoding and SBE encoding.

…

On Thu, Mar 10, 2022 at 1:56 PM Hanno Klein ***@***.***> wrote: 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> — Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7Z6SPEF6Z7IO3BSIBYDH3U7JAV5ANCNFSM5QKE5DKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[kleihan]

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]

This looks good to me

…

On Thu, Mar 10, 2022 at 5:22 PM Hanno Klein ***@***.***> wrote: 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> — Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7Z6SKU3C3NC72SPKCDE5TU7JY2RANCNFSM5QKE5DKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[jimnup]

Actually let's talk to Don about the first example - should everything be nested within a parent element that would be a child of AppInfo. I am not sure. Might be okay - might even be more flexible. We should validate with XMLSpy.

…

On Thu, Mar 10, 2022 at 6:54 PM Jim Northey ***@***.***> wrote: This looks good to me On Thu, Mar 10, 2022 at 5:22 PM Hanno Klein ***@***.***> wrote: > 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> > > — > Reply to this email directly, view it on GitHub > <#26 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB7Z6SKU3C3NC72SPKCDE5TU7JY2RANCNFSM5QKE5DKQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you commented.Message ID: > ***@***.*** > com> >

[donmendelson]

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]

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