-
Notifications
You must be signed in to change notification settings - Fork 2
[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
Comments
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.
|
So you are saying that 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? |
The purpose attribute is important - as it identifies what application the information pertains to. It is also benefits UI builders and processors. Your first example I believe is the most appropriate and you would have two AppInfos if needed for SBE and FIXML.
|
Although the SBE example - is just an example of course. I think Don has built in datatype mapping into Orchestra. Is that correct Don? |
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 <fixr:appInfo purpose="FIXML">
<encoding inline="1" notReqXML="1"/>
</fixr:appInfo>
<fixr:appInfo purpose="SBE">
<encoding semanticType="int"/>
</fixr:appInfo> |
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:
***@***.***>
|
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> |
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:
***@***.***>
|
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>
>
|
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> |
Looks good, changed the attribute from "inline" to "inlined" (see Unified schema). |
I am able to write appinfo element using the new schema, for example:
However, to make it work, I had to disable validation in the Python xmlschema library. The output will need to be validated externally. |
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> |
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 |
FIXML schema has a few inlined components:
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.
The text was updated successfully, but these errors were encountered: