This document provides best practices for naming conventions when defining message usage guidelines in MyStandards. It recommends structuring collection names based on organizational entity, locale or initiative, business area, business process, and version/status. For usage guideline names, it suggests including the message name and identifier for XML messages or message type for SWIFT messages. The document aims to promote consistency and formalization when specifying message restrictions to improve analysis and searchability.
Projecte d'optimització del seus procés d'innovació de producte per tal d'assegurar el flux normal en base a conceptes d'enginyeria concurrent i explotació de la multifuncionalitat
Caso práctico de definición de un sistema de gestión operativo con el análisis del mapa de procesos, organigrama, roles y job description, sistema de gestión y sistema de información
This presentation deals with the Performance testing implemented in the Project.
We have to use Certain Tools in the POC process.
1) VSTS
2) JMeter
finally, VSTS has been Implemented.
I hope this presentation helps the viewer to get the overview of the tools which Accenture Deals.
Projecte d'optimització del seus procés d'innovació de producte per tal d'assegurar el flux normal en base a conceptes d'enginyeria concurrent i explotació de la multifuncionalitat
Caso práctico de definición de un sistema de gestión operativo con el análisis del mapa de procesos, organigrama, roles y job description, sistema de gestión y sistema de información
This presentation deals with the Performance testing implemented in the Project.
We have to use Certain Tools in the POC process.
1) VSTS
2) JMeter
finally, VSTS has been Implemented.
I hope this presentation helps the viewer to get the overview of the tools which Accenture Deals.
Learn end-to-end SAP Concur with detailed explanation. Best tutorials for technical consultants, functional consultants and concur end users. Lifetime access to all tutorials with FREE updates on latest concur changes & technology. Grab the opportunity today just for $5. Limited Period offer.
Visit : sapexperts.thinkific.com
Catalog of Cognos Training courses PerformanceG2 offers onsite and online. Visit http://performanceg2.com/solutions/cognos-training/ for more information.
Building a microservice architecture for a 100mio# revenue companyProjectAcom
Project A's CTO Stephan Schulze presents in his talks his learnings when building a mircroservice architecture for a 100mio+ revenue company.
The talk was held at codetalks conference in Berlin, April 2017 by Stephan Schulze
(Twitter: @nahpeps)
Doctrain Life Sciences Handling Dita Topics And Translation In A Regulated ...Scott Abel
Presented by Jennifer Linton & Jennifer Perkins at Documentation and Training Life Sciences, June 23-26, 2008 in Indianapolis.
Gambro BCT, a medical device manufacturer, is diving in to the next generation of technical communications. This new environment consists of topic-based XML/DITA-structured authoring, automatic publishing, and the need increase the number of language offerings to support growth in additional and merging markets. All of this is to be done while continuing to follow regulatory guidelines.
In this discussion, Jennifer Perkins, the Technical Communications Manager, and Jennifer Linton, the XML/CMS Project Manager, provide helpful tips about each phase of the document lifecycle and what to consider when moving to an XML/DITA-based environment in a regulated industry. Do you have questions about how to support an XML/DITA-based and content and translation management system environment in your industry? This talk will provide you with some helpful tools and answers for you to move forward.
After about two and a half years of attempting to move to DITA and trying different content management system approaches, Gambro BCT is finally using the open source authoring standard, a content management system, and a translation management system. This new environment, called GEM (Globalization and English Management), is the basis for many new opportunities at Gambro BCT. They will share a brief overview of the organizational structure, tools infrastructure, and the regulatory standards needed to maintain this new environment. Then they will dive into some of the details about the discussions they had to solidify this working environment. These discussions include the information model, user guide for the content management system, persona descriptions, and process and procedure guides. For example, in their discussions, they determined that the document lifecycle needed to change to encourage regulatory signoff at a more granular level to promote a translations cost savings.
The presenters will also share the benefits that they foresee with this new environment as well as some lessons learned and next steps, including implementation of this system to develop training materials.
Learn end-to-end SAP Concur with detailed explanation. Best tutorials for technical consultants, functional consultants and concur end users. Lifetime access to all tutorials with FREE updates on latest concur changes & technology. Grab the opportunity today just for $5. Limited Period offer.
Visit : sapexperts.thinkific.com
Catalog of Cognos Training courses PerformanceG2 offers onsite and online. Visit http://performanceg2.com/solutions/cognos-training/ for more information.
Building a microservice architecture for a 100mio# revenue companyProjectAcom
Project A's CTO Stephan Schulze presents in his talks his learnings when building a mircroservice architecture for a 100mio+ revenue company.
The talk was held at codetalks conference in Berlin, April 2017 by Stephan Schulze
(Twitter: @nahpeps)
Doctrain Life Sciences Handling Dita Topics And Translation In A Regulated ...Scott Abel
Presented by Jennifer Linton & Jennifer Perkins at Documentation and Training Life Sciences, June 23-26, 2008 in Indianapolis.
Gambro BCT, a medical device manufacturer, is diving in to the next generation of technical communications. This new environment consists of topic-based XML/DITA-structured authoring, automatic publishing, and the need increase the number of language offerings to support growth in additional and merging markets. All of this is to be done while continuing to follow regulatory guidelines.
In this discussion, Jennifer Perkins, the Technical Communications Manager, and Jennifer Linton, the XML/CMS Project Manager, provide helpful tips about each phase of the document lifecycle and what to consider when moving to an XML/DITA-based environment in a regulated industry. Do you have questions about how to support an XML/DITA-based and content and translation management system environment in your industry? This talk will provide you with some helpful tools and answers for you to move forward.
After about two and a half years of attempting to move to DITA and trying different content management system approaches, Gambro BCT is finally using the open source authoring standard, a content management system, and a translation management system. This new environment, called GEM (Globalization and English Management), is the basis for many new opportunities at Gambro BCT. They will share a brief overview of the organizational structure, tools infrastructure, and the regulatory standards needed to maintain this new environment. Then they will dive into some of the details about the discussions they had to solidify this working environment. These discussions include the information model, user guide for the content management system, persona descriptions, and process and procedure guides. For example, in their discussions, they determined that the document lifecycle needed to change to encourage regulatory signoff at a more granular level to promote a translations cost savings.
The presenters will also share the benefits that they foresee with this new environment as well as some lessons learned and next steps, including implementation of this system to develop training materials.
Similar to 3 mystandards ug_editor_best_practices (20)
What price will pi network be listed on exchangesDOT TECH
The rate at which pi will be listed is practically unknown. But due to speculations surrounding it the predicted rate is tends to be from 30$ — 50$.
So if you are interested in selling your pi network coins at a high rate tho. Or you can't wait till the mainnet launch in 2026. You can easily trade your pi coins with a merchant.
A merchant is someone who buys pi coins from miners and resell them to Investors looking forward to hold massive quantities till mainnet launch.
I will leave the telegram contact of my personal pi vendor to trade with.
@Pi_vendor_247
BYD SWOT Analysis and In-Depth Insights 2024.pptxmikemetalprod
Indepth analysis of the BYD 2024
BYD (Build Your Dreams) is a Chinese automaker and battery manufacturer that has snowballed over the past two decades to become a significant player in electric vehicles and global clean energy technology.
This SWOT analysis examines BYD's strengths, weaknesses, opportunities, and threats as it competes in the fast-changing automotive and energy storage industries.
Founded in 1995 and headquartered in Shenzhen, BYD started as a battery company before expanding into automobiles in the early 2000s.
Initially manufacturing gasoline-powered vehicles, BYD focused on plug-in hybrid and fully electric vehicles, leveraging its expertise in battery technology.
Today, BYD is the world’s largest electric vehicle manufacturer, delivering over 1.2 million electric cars globally. The company also produces electric buses, trucks, forklifts, and rail transit.
On the energy side, BYD is a major supplier of rechargeable batteries for cell phones, laptops, electric vehicles, and energy storage systems.
How to get verified on Coinbase Account?_.docxBuy bitget
t's important to note that buying verified Coinbase accounts is not recommended and may violate Coinbase's terms of service. Instead of searching to "buy verified Coinbase accounts," follow the proper steps to verify your own account to ensure compliance and security.
Even tho Pi network is not listed on any exchange yet.
Buying/Selling or investing in pi network coins is highly possible through the help of vendors. You can buy from vendors[ buy directly from the pi network miners and resell it]. I will leave the telegram contact of my personal vendor.
@Pi_vendor_247
how to sell pi coins effectively (from 50 - 100k pi)DOT TECH
Anywhere in the world, including Africa, America, and Europe, you can sell Pi Network Coins online and receive cash through online payment options.
Pi has not yet been launched on any exchange because we are currently using the confined Mainnet. The planned launch date for Pi is June 28, 2026.
Reselling to investors who want to hold until the mainnet launch in 2026 is currently the sole way to sell.
Consequently, right now. All you need to do is select the right pi network provider.
Who is a pi merchant?
An individual who buys coins from miners on the pi network and resells them to investors hoping to hang onto them until the mainnet is launched is known as a pi merchant.
debuts.
I'll provide you the Telegram username
@Pi_vendor_247
where can I find a legit pi merchant onlineDOT TECH
Yes. This is very easy what you need is a recommendation from someone who has successfully traded pi coins before with a merchant.
Who is a pi merchant?
A pi merchant is someone who buys pi network coins and resell them to Investors looking forward to hold thousands of pi coins before the open mainnet.
I will leave the telegram contact of my personal pi merchant to trade with
@Pi_vendor_247
Currently pi network is not tradable on binance or any other exchange because we are still in the enclosed mainnet.
Right now the only way to sell pi coins is by trading with a verified merchant.
What is a pi merchant?
A pi merchant is someone verified by pi network team and allowed to barter pi coins for goods and services.
Since pi network is not doing any pre-sale The only way exchanges like binance/huobi or crypto whales can get pi is by buying from miners. And a merchant stands in between the exchanges and the miners.
I will leave the telegram contact of my personal pi merchant. I and my friends has traded more than 6000pi coins successfully
Tele-gram
@Pi_vendor_247
The European Unemployment Puzzle: implications from population agingGRAPE
We study the link between the evolving age structure of the working population and unemployment. We build a large new Keynesian OLG model with a realistic age structure, labor market frictions, sticky prices, and aggregate shocks. Once calibrated to the European economy, we quantify the extent to which demographic changes over the last three decades have contributed to the decline of the unemployment rate. Our findings yield important implications for the future evolution of unemployment given the anticipated further aging of the working population in Europe. We also quantify the implications for optimal monetary policy: lowering inflation volatility becomes less costly in terms of GDP and unemployment volatility, which hints that optimal monetary policy may be more hawkish in an aging society. Finally, our results also propose a partial reversal of the European-US unemployment puzzle due to the fact that the share of young workers is expected to remain robust in the US.
how to sell pi coins on Bitmart crypto exchangeDOT TECH
Yes. Pi network coins can be exchanged but not on bitmart exchange. Because pi network is still in the enclosed mainnet. The only way pioneers are able to trade pi coins is by reselling the pi coins to pi verified merchants.
A verified merchant is someone who buys pi network coins and resell it to exchanges looking forward to hold till mainnet launch.
I will leave the telegram contact of my personal pi merchant to trade with.
@Pi_vendor_247
how can I sell pi coins after successfully completing KYCDOT TECH
Pi coins is not launched yet in any exchange 💱 this means it's not swappable, the current pi displaying on coin market cap is the iou version of pi. And you can learn all about that on my previous post.
RIGHT NOW THE ONLY WAY you can sell pi coins is through verified pi merchants. A pi merchant is someone who buys pi coins and resell them to exchanges and crypto whales. Looking forward to hold massive quantities of pi coins before the mainnet launch.
This is because pi network is not doing any pre-sale or ico offerings, the only way to get my coins is from buying from miners. So a merchant facilitates the transactions between the miners and these exchanges holding pi.
I and my friends has sold more than 6000 pi coins successfully with this method. I will be happy to share the contact of my personal pi merchant. The one i trade with, if you have your own merchant you can trade with them. For those who are new.
Message: @Pi_vendor_247 on telegram.
I wouldn't advise you selling all percentage of the pi coins. Leave at least a before so its a win win during open mainnet. Have a nice day pioneers ♥️
#kyc #mainnet #picoins #pi #sellpi #piwallet
#pinetwork
what is the best method to sell pi coins in 2024DOT TECH
The best way to sell your pi coins safely is trading with an exchange..but since pi is not launched in any exchange, and second option is through a VERIFIED pi merchant.
Who is a pi merchant?
A pi merchant is someone who buys pi coins from miners and pioneers and resell them to Investors looking forward to hold massive amounts before mainnet launch in 2026.
I will leave the telegram contact of my personal pi merchant to trade pi coins with.
@Pi_vendor_247
1. Standards
MyStandards
Usage Guideline Editor
Best Practices
This document provides best practice recommendations for users of the MyStandards Usage Guideline Editor
defining their message usage guidelines.
20 June 2012
2. MyStandards
2 Best Practices
Table of Contents
Table of Contents...............................................................................................................................2
Preface.................................................................................................................................................3
1 Introduction...............................................................................................................................4
2 Naming Conventions................................................................................................................5
2.1 Introduction .............................................................................................................................5
2.2 Collection Name......................................................................................................................5
2.2.1 Examples............................................................................................................................ 5
2.3 Usage Guidelines....................................................................................................................6
2.3.1 Examples............................................................................................................................ 6
3 Usage Guideline Editor Conventions.....................................................................................8
3.1 Introduction .............................................................................................................................8
3.2 Must not Be Used (Remove)...................................................................................................8
3.3 Make Mandatory .....................................................................................................................9
3.4 Reduce Multiplicity ..................................................................................................................9
3.5 Ignore ....................................................................................................................................10
3.6 Rules (and Guidelines)..........................................................................................................10
3.6.1 Text Rule or Guideline...................................................................................................... 11
3.6.2 Conditional Rule ............................................................................................................... 11
3.7 Fixed Value ...........................................................................................................................14
3.8 Comment...............................................................................................................................15
3.9 Annotation .............................................................................................................................16
3.9.1 Example 1......................................................................................................................... 17
3.9.2 Example 2......................................................................................................................... 18
3.9.3 Example 3......................................................................................................................... 18
3.10 Change Datatype ..................................................................................................................19
3.10.1 Redefine a Text or Narrative Field as a Code List............................................................ 19
3.10.2 Redefine a Narrative Field as Structured Lines of Text (MT) ........................................... 20
3.11 Create Extension (MX Only) .................................................................................................21
3.11.1 Scenario 1: Fixed Value ................................................................................................... 21
3.11.2 Scenario 2: Fixed Value and Code List ............................................................................ 24
3.12 Synonyms .............................................................................................................................27
4 Collections and Usage Guidelines .......................................................................................28
Legal Notices ....................................................................................................................................29
3. Preface
20 June 2012 3
Preface
Purpose of the document
This document provides best practice recommendations for users of the MyStandards Usage
Guideline Editor defining their message usage guidelines.
Audience
This document is for the following audience:
· Users of the MyStandards Usage Guideline Editor
Significant changes
The following tables list all significant changes to the content of the MyStandards Best Practices
since the 27 April 2012 edition. These tables do not include editorial changes that SWIFT makes
to improve the usability and comprehension of the document.
New information Location
New section on collections and usage
guidelines
4 Collections and Usage Guidelines
Updated information Location
Changes to naming conventions for collections
and usage guidelines
2.2 Collection Name
2.3 Usage Guidelines
Related documentation
· MyStandards Service Description
· MyStandards Best Practices
4. MyStandards
4 Best Practices
1 Introduction
This document describes naming conventions and recommended approaches when specifying
restrictions on message fields.
It is important to have a convention when naming collections and guideline definitions so that
there is a level of consistency with names and to support the easy searching of guideline
definitions.
The driving principle behind having best practices is to push users to formalise as much as
possible. The more formal a usage guideline definition is, then the more semantic value it has
and so the more meaningful any automated or manual analysis can be.
This document is intended for those users that already have a good knowledge of the
MyStandards Usage Guideline Editor. It is not a user manual.
In most cases, the best practice principals used are the same or similar for both MT and MX.
Where illustrations are used, MX (XML) messages has been used.
5. Naming Conventions
20 June 2012 5
2 Naming Conventions
2.1 Introduction
The naming conventions described below for collections and usage guidelines functionality are
valid, although practically, there may be variants.
2.2 Collection Name
A collection is a container of logical set of guideline definitions which the user must analyse and
manage.
The table below gives an overview of how to build up the collection name.
Parameter Description Example
1 Organisational Entity - SMPG, NMPG, RMPG, CGI, PMPG
2 [Locale or initiative -] Global, IT, GB, FR, Almus
3 Business area - CA, TIC, SR, IF, Payments, FX, Derivatives, Commodities
4
Business process -
Events, Order & Confirmation, Block Trade, Order Status
& Confirmation, Transfers, Price Reporting, High Value
Payments
5 Version - V1, V2, V3
6 Status_ DRAFT, FINAL, WIP
CA = Corporate Actions TIC = Trade Initiation & Confirmation SR = Settlement & Reconciliation
IF = Investment Funds WIP = Work in progress CGI = Common Global Implementation
Warning Optional parameters are indicated by square brackets [].
Versioning
MyStandards has its own convention for versioning and will apply Version 1 to the first time a
collection is uploaded, and increment the version number of subsequent uploads. This is a
technical version number and is distinct from the "true" version number of a collection. For
example, V1 of the IF-Orders, Status and Confirmations collection may have been updated
several times as several iterations of a "work-in-progress" version are posted. Thus Version 1 of
the IF Orders and Confirmations collection may have, for example, an internal MyStandards
version number of 5. Therefore, there is a need for a "business version number".
2.2.1 Examples
The spaces in the following example collection names are present for readability, they do not
have to be present in the actual collection name, it is up to the user.
SMPG
# Collection Name
1 SMPG - Global - TIC - Order & Confirmation - V1 – FINAL_
2 SMPG - Global - SR Block Trades - V1 – FINAL_
3 SMPG - Global - CA - Events - V2 – DRAFT_
4 SMPG - Global - IF - Order Status & Confirmations - V1 – DRAFT_
NMPG
# Collection Name
6. MyStandards
6 Best Practices
1 NMPG - FR - IF - Order & Confirmation - V1 – FINAL_
2 NMPG - DE - IF - Price Reporting - V1 – FINAL_
3 NMPG - DE - IF - Statements - V3 – DRAFT_
4 NMPG - US – TIC - Trade Initiation & Confirmation - V1 – DRAFT_
RMPG
# Collection Name
1 RMPG – ALMUS - IF - Order & Confirmation - V1 – FINAL_
2 RMPG - AFAC - IF - Order & Confirmation - V1 – FINAL_
3 RMPG - FINDEL - IF - Order & Confirmation - V2 – FINAL_
4 RMPG - FINDEL - IF - Transfer - V1 – DRAFT_
5 RMPG - SHARP - IF - Order & Confirmation - V1 – FINAL_
CGI
# Collection Name
1 CGI - Global - Payments -Corporate to Bank - V1 – FINAL_
PMPG
# Collection Name
1 PMPG - Global - Payments -PACS High Value Payments - V1 – FINAL_
2.3 Usage Guidelines
A usage guideline represents a message definition which has been restricted by the user.
The table below gives an overview of how to build up the usage guideline name for the MX or
ISO 20022 XML messages:
Parameter Description Example
1 Message Name &
Identifier
Subscription Order_ setr.010.001.03
2 [ Additional optional
parameter - ]
Subscription Leg, Redemption Leg
The table below gives an overview of how to build up the usage guideline name for the MT:
Parameter Description Example
1 Message Identifier &
Message Name -
541_ Receive Against Payment
2 [For MT: SR year - ] SR2011, SR2012
3 [ Additional optional
parameter - ]
Bonus Issue
Warning Optional parameters are indicated by square brackets [].
2.3.1 Examples
The spaces in the following examples of collection and usage guideline names are present for
readability, they do not have to be present in the actual collection name, it is up to the user.
7. Naming Conventions
20 June 2012 7
SMPG
# Usage Guideline Name
1 541_Receive Against Payment
2 502_Order To Buy Or Sell - SR2011 - Subscription Leg
3 Subscription Order_setr.010.001.03 - Institutional
4 Subscription Order_setr.010.001.03
CGI
# Usage Guideline Name
1 Customer Credit Transfer Initiation_pain.001.001.03 - ACH Domestic & International
2 Customer Credit Transfer Initiation_pain.001.001.03 - Wires Domestic & International
3 Customer Credit Transfer Initiation _pain.001.001.03 - Cheques / Drafts
PMPG
# Usage Guideline Name
1 FI To FI Customer Credit Transfer_pacs.008.001.02 - IG
2 Financial Institution Credit Transfer_pacs.008.001.02 - IG General
3 Financial Institution Credit Transfer_pacs.008.001.02 - IG Cover
Other, for example, commodities
# Usage Guideline Name
1 600_Commodity Trade Confirmation
Note When a message is added to a collection, the name of the collection is automatically
appended in front of the message name. The collection name should be deleted from
the message name.
8. MyStandards
8 Best Practices
3 Usage Guideline Editor Conventions
3.1 Introduction
The Usage Guideline Editor makes it very easy for a user to accurately and unambiguously
describe their specific usage of a message. It allows a user to easily apply additional restrictions
on top of the base message definition.
Note A "restriction" is an additional limitation defined by the user on the base message
definition which an implementer would need to follow in order to be compliant with the
guideline. In some contexts the term "rule" would be used instead of "restriction".
The list below describes the different restriction types that may be applied:
# Restriction Type Description
1
Must not be used
(Remove)
An optional field or element must not be populated.
2 Make Mandatory An optional field or element must be populated.
3 Reduce Multiplicity A repeating field or element must repeat fewer times.
4 Ignore
A field or element could be populated but is ignored by the
receiver.
5 Text Rule A mandatory, unstructured, rule.
6 Conditional Rule A mandatory, if-then-else, rule.
7 Fixed Value A field or element must contain a given value.
8 Comment
Information which cannot be expressed in a more
structured way.
9 Annotation
A user-defined structure if a built in restriction is
insufficient.
10 Change Datatype
A user-defined datatype replaces an existing simple
datatype.
11 Create Extension A user-defined extension - MX specific.
12 Synonym A field or element has another name.
The first four basic restriction types are very easy to set up in the message usage editor in an
unambiguous way.
The other more advanced restriction types, such as rules, comments and annotations require
more thought before their use. It’s possible to confuse their distinct functionality and the next
sections attempts to define when it is appropriate to use each kind of functionality.
3.2 Must not Be Used (Remove)
Indicating a field must not be used (removed), means that in order to be compliant with the user-
defined guideline, a particular field must not be populated.
If the sender of a message does populate the "removed" field, then the message will not be
viewed as being compliant to the usage guideline. As a result, the receiver of the message may
stop any processing and end the business transaction.
Care must be taken when using this functionality since its implementation may be costly to the
sender, if the sender has already implemented the message. An alternative solution that
minimises the impact on a message already implemented by the sender is "Ignore" – in other
words, a field or element may be populated by the sender but it is ignored by the receiver.
9. Usage Guideline Editor Conventions
20 June 2012 9
3.3 Make Mandatory
Making an optional field mandatory, means that in order to be compliant with the user-defined
guideline, a particular field must be populated.
If the sender of a message does not populate the "mandatory" field, then the message will not be
viewed as being compliant to the usage guideline. As a result, the receiver of the message may
stop any processing and end the business transaction.
3.4 Reduce Multiplicity
Some fields are defined in the base message as being repeatable. The user-defined guideline
could contain a restriction which reduces the amount of times a field can be repeated.
If the sender of a message repeats a field more times than is allowed in the usage guideline,
then the message will not be viewed as being compliant. As a result, the receiver of the message
may stop any processing and end the business transaction.
It is not possible to increase the multiplicity of a field or element.
10. MyStandards
10 Best Practices
3.5 Ignore
Indicating a field must be ignored, means that in order to be compliant with the user-defined
guideline, a particular field may or may not be populated.
If the sender of a message does populate the "ignored" field, then the message is still viewed as
being compliant to the usage guideline. However, the receiver of the message will not use the
data in any way. In other words, the data in the field will not influence either the processing or the
business transaction.
3.6 Rules (and Guidelines)
Over and above restrictions such as "must not use" (remove), "must be used", "use only once"
and "ignore", additional rules may be added to a field, which means that in order to be compliant
with the user-defined guideline, the rule must be followed.
If the sender of a message does not follow the additional rule on a field, then the message will
not be viewed as being compliant to the usage guideline. As a result, the receiver of the
message may stop any processing and end the business transaction.
1. A rule should contain a single constraint. If more than one rule constraint is necessary on a
single field, these should be added in additional, separate rules.
2. The rule should be given a meaningful name. It is sensible to differentiate message usage
rules or guidelines from the rules and guidelines actually present in the message standard.
Prefixing the rule name with something like "ITNMPG" will help with this differentiation. Each
rule should end in the word "Rule".
3. If a text rule (see below) is to be considered a guideline rather than a rule, then the rule
name should end in the word "guideline".
4. Where possible, it is recommended to use the "Conditional Rule" format, over the "Text
Rule" format as it increases interpretation clarity.
5. A rule should not be added if it is already part of, or conflicts with, the base message
standard definition.
11. Usage Guideline Editor Conventions
20 June 2012 11
6. Do not use punctuation, spaces or underscore types of characters. Follow the camel case
convention. These restrictions are to allow for potential future functionality.
7. The cross element rule checkbox should be used as necessary.
Differentiation between a Rule and a Guideline.
Type Description Example
Guideline
Compliance is recommended and
so often contains the word "may".
· "The use of an ISIN is recommended."
· "The field may be used to quote the
reference of the account opening
instruction."
Rule
Compliance is mandatory and so
contain the word "must".
· "The field must contain the reference
of the account opening instruction."
3.6.1 Text Rule or Guideline
This is a simple usage rule which is described in a plain text paragraph. It will require the user to
interpret the rule carefully. So, it is recommended that the rule is concise and precise language is
used.
Example 1 – text rule
Example 2 – guideline
3.6.2 Conditional Rule
1. The rule is added to the first element (as referenced in <element>) of the conditional rule.
2. It is recommended that the rule definition is empty. In most cases the "if-then-else" text
fields should be sufficient to describe the rule.
12. MyStandards
12 Best Practices
3. When referring to other fields in the rule, then the XML tag or field name must be used. In
some cases, it may be necessary to include some "path" information (see example below).
Path information may also be needed in those cases where the same element name is used
in different parts of the message.
4. Recommended structures of the "if", "then" and "else" text boxes is: <element> <logic> [
<value> ]
- <element> represents the element or field being referenced.
- <logic> represents the operator
- <value> optional value to which relates to the content in <element>
Example usage would be:
<element> <logic> <value> <element> <logic> <value> <element>
<logic>
<value>
If Currency is
equal
to
EUR Then Amount must not contain
decimals
Else Amount
may
contain
decimals
If OrdrTp/ST
AF
is
presen
t
Then StafClntBrkdwn/OrdrBrkdwnTp/
NSPN must be present
14. MyStandards
14 Best Practices
Example 2
3.7 Fixed Value
Setting a fixed value for a field, means that in order to be compliant with the user-defined
guideline, a particular field, when present, must be populated with the specified fixed value.
If the sender of a message does not populate the field with the fixed value, then the message will
not be viewed as being compliant to the usage guideline. As a result, the receiver of the
message may stop any processing and end the business transaction.
A fixed value may only be used on fields containing simple types, for example, Max35Text or
Extended350Code. Examples of fixed field values are a user-defined code word, or a specific
currency code.
15. Usage Guideline Editor Conventions
20 June 2012 15
The fixed value is entered in the "Fixed value" text field. If the fixed value is a code, then the
definition of the code should be specified in the associated comment box. Note that a separate
definition box for fixed value has been requested.
3.8 Comment
A comment can only be used to contain information which cannot be expressed using more
structured restriction types, like "make mandatory" or "must not be used". So, it should only be
populated if a more restrictive restriction type cannot be used. It is "for information only".
Don’t use a comment for the following:
· To redefine the semantic of a field.
· To create a local language definition.
· To redefine the base message standard definition.
· To state the field is "recommended". If a field is recommended, this is better expressed as a
guideline, using the "Add rule" functionality.
· To specify a fixed value. This is to be expressed using the Fixed Value box. However, the
comment box is used to give the definition of the fixed value when it is a code word, until the
Fixed Value has its own definition box.
16. MyStandards
16 Best Practices
Example
3.9 Annotation
The built-in restriction types may not cover all the scenarios which a user may need to apply in
their usage guideline. The annotation mechanism allows the user to create a re-usable restriction
type to cover its particular requirement.
So, annotations should only be used when it is not possible to express the message usage
information through one of the "normal" mechanisms. For example, do not use an annotation to
define a rule or to or to express a fixed value.
Note The MyStandards platform has no knowledge of the semantics of annotations – there
is no impact on the generated schema. An annotation appears in the generated
spreadsheet in the Annotation column.
17. Usage Guideline Editor Conventions
20 June 2012 17
Annotations should be given meaningful names and definitions:
3.9.1 Example 1
The IT NMPG, for example, has the need to attach change request information to a field. An
annotation function can be defined for such usage:
18. MyStandards
18 Best Practices
3.9.2 Example 2
The IT NMPG, for example, has the need to redefine the semantic of an element for local use.
An annotation function can be defined for such usage:
3.9.3 Example 3
The IT NMPG, for example, has the need to include definitions in Italian:
19. Usage Guideline Editor Conventions
20 June 2012 19
3.10 Change Datatype
Some fields are defined in the base message as being "simple data types", such as text, a
number, a date. The user may choose to redefine a field's simple datatype to a more restrictive
existing datatype, which is already available in the repository, or to use a newly created datatype.
It is recommended to re-use existing datatypes.
3.10.1 Redefine a Text or Narrative Field as a Code List
A user may redefine a text field as a code list, to enable a more formal way of specifying that, for
example, "this field may contain the values SPEC and XPEC".
This involves two steps, first, the setting up of the new code list and, secondly, redefining the
type of the relevant field to use the new code list.
When setting up the new code list, care must be taken to give the code list datatype a meaningful
name:
A definition at this level is probably not necessary.
20. MyStandards
20 Best Practices
The individual codes must be entered, and each code must be given a code word and a
definition:
3.10.2 Redefine a Narrative Field as Structured Lines of Text (MT)
A user may redefine a narrative field, for example, 6 * 35x, so that it is more structured.
This involves two or three steps, depending on the requirements. First, the new complex type is
set up. And second, the relevant field is typed by the new complex type. When setting up the
new complex datatype, care must be taken to make sure it and all its subfields have relevant
names and, if necessary, meaningful definitions. And for the subfields, multiplicity must be set to
override the default multiplicity proposed by the usage guideline editor. In turn, each of the
subfields can each have their own datatype.
Example
In this scenario, in a usage guideline for the MT 502, field 70E (10*35X) TPRO in sequence B
ORDRDET, is re-defined in the following way:
Original definition in MT New definition
Data Type
10 * 35x Line 1 Subfield 1 Code list with values
NEAM and GRAM and
GRPE
Line 2 Subfield 2 3!a – currency code
Line 3 Subfield 3 15d
21. Usage Guideline Editor Conventions
20 June 2012 21
3.11 Create Extension (MX Only)
Because the investment funds order messages have not been maintained for some considerable
time, many markets have defined the use of the Extension sequence for additional functionality,
pending the maintenance.
Extension sequence
3.11.1 Scenario 1: Fixed Value
There is a requirement to be able to optionally specify an SLA Reference in the Charge Details
sequence of a message. The NMPG has agreed that this should be specified in an Extension
sequence.
An iteration of an Extension sequence is inserted in the Charge Details sequence. Following the
addition of a new Extension sequence, give it a meaningful name and definition:
23. Usage Guideline Editor Conventions
20 June 2012 23
For each of the elements of the Extension sequence, you need to define the contents (2):
24. MyStandards
24 Best Practices
3.11.2 Scenario 2: Fixed Value and Code List
There is a requirement to be able to optionally specify information about "order sequencing" in
the message. The order sequencing can be either FIST (first) or FIILW (additional order).
The NMPG has agreed that this should be specified in an Extension sequence.
An iteration of an Extension sequence is inserted in the Individual Order Details sequence.
Following the addition of a new Extension sequence, give it a meaningful name and definition:
25. Usage Guideline Editor Conventions
20 June 2012 25
For each of the elements of the Extension sequence, you need to define the contents (1):
26. MyStandards
26 Best Practices
The first element will be defined with "Fixed value" and this will be the XML path. A comment for
the fixed value is entered.
For each of the elements of the Extension sequence, you need to define the contents (2):
27. Usage Guideline Editor Conventions
20 June 2012 27
In this example, the second element (Text: Max350Text) can be one of two codes and therefore
a code list has been created and the element Text has been typed by it (See Redefine a Text or
Narrative Field as a Code List).
3.12 Synonyms
Every field in a base message has a specific name with associated meaning. A user-defined
guideline may link another name, from a different context, to the given field.
Examples:
· A back-office system may use another, proprietary, format. This proprietary format also has
fields which match fields in the base message. A synonym can then be used to link the base
message field to the proprietary format field.
· A non-English speaking country may want to use the base message, however the fact that
all base messages are in English means adoption is hampered. A synonym can then be
used to link the base message field to the translation of that field which should ease
adoption.
28. MyStandards
28 Best Practices
4 Collections and Usage Guidelines
A collection is a container of logical set of guideline definitions which the user must analyse and
manage.
Typically, a "collection" will be for a specific business process and contain usage guidelines for
messages that support the business process.
Example
There will be cases where a collection contains a single message. Publishers of usage
guidelines, market practices, implementation guidelines, etc., on MyStandards should try to
organise their work so that it’s published as a logical collection.