2013-03-14 Candidate schemas for Xml4Sak created ------------------------------------------------- 1. Element Insured has been removed from the schema based on a decision on 2013-03-07. 2013-03-20 First on-line conference to finalise Xml4Sak schemas ---------------------------------------------------------------- 1. Premium structure questioned; the current structure is based on the inital draft and is designed based on the brokered definition. Perhaps other definitions and structures should be entertained before we finalise things. Edward was tasked with starting an email discussion regarding this in order to get additional input to next weeks meeting. 2. Pluralised lists versus just listing the items? vs The group decided to remove pluralised lists since we don't use it for phone numbers etc. Unless there is a reason for it we should not introduce additional elements. | The element Documents have been removed from the global namespace. | The types InsurancesType and DocumentsType have been removed from the global namespace. | The local elements Documents and Insurances have been removed from the abstract base | insurance type and replaced with unbounded Document and Insurance elements. | The local element Insurances have been removed from the PortfolioType and replaced | with an unbounded Insurance element. 3. The term insurance was questioned. Isn't the correct and more common term policy? A decision to change insurance to policy was agreed upon. | Insurance has been replaced by InsurancePolicy or Policy where applicable. All | descriptions are updated accordingly. 4. The portfolio schema structure was discussed. Anders presented another representation which raised a few questions regarding structure/information versus application. Current:
Suggested:
What happens when the message is something other than Portfolio, what about Claims etc.? Will all applications use the root Xml4Sak but in different namespaces? Are we risking a collision when combining schemas? A suggestion was to move common structures to the messaging schema. How will this resolve the problem? Will we extend using xs:Any or through inheritance? Edward was tasked with starting an email discussion regarding this in order to get additional input to next weeks meeting. | An attempt to solve this using an abstract body has been implemented. Awaiting | feedback from the mail discussion to see wether this structure should remain. 5. Currently the abstract base insurance contains other insurances. This allows for an infinite recursion. It was suggested that the recursion is moved from the base type to individual implementations. Typically there would be a generic type which doesn't allow recursion and another generic type that may contain other insurances. Edward will update the schema by moving the recursive element from the abstract base type to an implemenation type. | The list of insurances (see 2 above) in the abstract base type InsurancePolicyType has | been removed. No change to the GenericInsurancePolicyType is required since it now | represents an insurance policy that does not contain other insurance policies or | exposures. A new CombinedInsurancePolicyType has been introduced that extends the | abstract base InsurancePolicyType with an unbounded InsurancePolicyType element making | combined insurance policies and insurance policies with exposures possible without | infinite recursion. 2013-03-26 On-line conference to finalise Xml4Sak schemas ---------------------------------------------------------- 1. Consensus that the messaging structure is correct and funtional. Schemas xml4sak-messaging.xsd and xml4sak-portfolio.xsd are complete with the caveat that the namespace must be finalized. | Removed all commented out structures and miscellaneous comments from the schemas. 2. The name of the element AssignedBroker came into question since the purpose really is to group InsurancePolicies belonging to a portfolio together. It was decided to change the name of the element to PortfolioCode and update the description. | Changed AssignedBroker to PortfolioCode and updated the descriptions (see below). | Portfolio Code: Identifies the protfolio that the insurancepolicy belongs to. | Beståndskod: Identifierar det bestånd försäkringen är knuten till. | Changed the reference in InsurancePoliyType from AssignedBroker to PortfolioCode. | Changed the name of the type from BrokerType to PortfolioCodeType. | Changed the english description to fokus on the portfolio code and not the broker. 3. Premiums! We did not manage to find an adequate naming, structure or description of the various premiums during this meeting. It was decided that the group should look into this area until the next meeting and then present various alternatives. 4. The final namespace hasn't been finalised yet. Anders will look into where the schemas should be presented on the web site, i.e. which URL to use for the RDDL files. This URL will then be used for the schema namespace. 2013-04-03 On-line conference to finalise premiums structure ------------------------------------------------------------- 1. Discussion regarding namespaces and, location and presence on the internet resultet in RDDL (Resource Directory Description Language) being suggested for http://www.xml4sak.com/schemas/xml4sak. The RDDL at this location should refer to the current, latest and previous version. Specific versions extend the above URL with a version tag; http://www.xml4sak.com/schemas/xml4sak/v2. Anders will look into RDDL. He hoped his developer should have something available on xml4sak.com this friday. 2. The Premium construction was put to question and alternatives were suggested. One alternative that proved promising was to qualify the periodicity of a premium using an attribute in order to separate normal reoccuring premiums from limited time ones and other variants without having names like AnnualPremium. Se exempel nedan. 2013-01-01T00:00:00 2014-01-01T00:00:00 Gross=Net+Commission 1125 1000 125 12.5 administrative Administrativa avgifter 75 Vägtrafikskatt 100 In the example above we give a typr for the premium; annual, period, one-time or transaction. We can give a period for the premium. Vi can give one or more formulas showing how the various components relate to each other. 3. Anders mentioned that nillable="true" is used frequently in another related standard. He was unsure of the reasoning behind this and had contacted them for clarification. He admonished us to consider it's use and to give a motivation to if we should use it or not. If it were to be used we should give clear directives regarding in which circumstances it is permissable to use this construction. ⁞ The attribute nillable is only valid when declaring elements and not types. It is ⁞ mutually exclusive with the attribute ref so it can not be used on elements that uses ⁞ ref rather than declaring a type. This may have an impact on our design. ⁞ If an element is set to nillable="true" it is permissable to have an empty element in ⁞ the xml with the attribute xsi:nil="true". This would indicate that the value is ⁞ unknown. This is an important distinction since the exclusion of an element which ⁞ allows minOccurs="0" only indicates that the element wasn't supplied not wether the ⁞ information is unknown ot not. Furthermore this differs from an empty element without ⁞ xsi:nil="true" since this can be interpreted differently depending on the type for the ⁞ element. An empty integer will give a validation error whereas an empty string element ⁞ can be interpreted as an empty string. ⁞ ⁞ Examples: ⁞ In the schema: is invalid. ⁞ ⁞ The below construction would signal that the PolicyHolder is unknown. ⁞ ⁞ ⁞ Given it isn't possible to determine if the value is empty string or if ⁞ it is missing. The sender can have sent an empty string because they do not know the ⁞ value and the element is required. 4. Tomas question the naming of Commission and wanted us to look into alternative names. 2013-04-11 On-line conference to finalise xml4sak -------------------------------------------------- 1. A discussion regarding the formula describing the relationship between parts of the premium resulted in the formula being removed from the schema and placed in the documentation. We decided to use a type attribute to define which calculation should be used. This attribute would contain a name of a predefined calculation described in the documentation or a custom name referring to a calculation described in the documentation of the information exchange in question. As a result the Formula element will be removed and the current type attribute will be renamed to periodicity. | The element AnnualPremium was renamed Premium and the documentation was changed from | "Annual premium: The annual premium for the insurance policy" and "Årspremie: Aktuella | premier för försäkringen" to "Premium: The current premium for the insurance policy" | and "Premie: Aktuella premier för försäkringen". | ⁞ Premium is required and can only occur once, is it really so? Do we always wish to ⁞ send a premium along with our insurance information? Is it not possible that we want ⁞ to send information that there is a valid insurance policy without saying how much the ⁞ policyholder is paying for the insurance policy? Since we have introduced a type on ⁞ the premium is it not possible that we want to transmitt more than one premium type ⁞ for the insurance, i.e. brokered premium as well as premium written? ⁞ ⁞> We must update the description for GrossPremium since it is no longer correct with ⁞ regards to the new PremiumType. ⁞ ⁞> We must update the descriptions for Netpremium, Surcharge and Tax for the same reason. ⁞ | The attribute type was added to the PremiumType. It is a union of an enumeration of | premium types and the token type in order for it to be extensible. The only predefined | type so far is "remuneration". | Added to the PremiumType was an attribute named periodicity with values from an | enumeration; annual, period, one-time and transaction. Also added to the PremiumType | was an element named Period of type PeriodType which should be used to defined the | period for the premium since it can differ from both agreement and insurance period. 2. We discussed whether Xml4Sak should be spelled XML4Sak, Xml4Sak or xml4sak. Initially we leaned towards using Xml4Sak in the schema and xml4sak in the namespace. We finally decided to use the same spelling in all references; schema, namespace and documentation. | Changed all references to Xml4Sak so that the casing matches, i.e. initial uppercase | letter for Xml and for Sak, lowercase for remaing letters. Namespaces, filenames, | elements and documentation updated in Xml4Sak-portfolio.xsd, Xml4Sak-messaging.xsd, | Xml4Sak-basetypes.xsd. 3. We agreed to move the Type element for Surcharge and implement it as an attribute on Surcharge instead in order to maintain a consistent design throughout. | I moved the definition for the element Type so that it defines an attribute type | instead. No other changes were made. | | | | | | became | | | 4. We agreed to rename Commission to Remuneration. | Changed the name of the Commission element to Remuneration and updated the description | from "Commission: Represents a commission or fee." to "Remuneration: Represents a | remuneration, typically a commission or fee." | | Changed the name of CommissionType to RemunerationType. I also updated the | documentation for the amount from "Amount: The calculated commission based on the | commisson type" to "Amount: The calculated remuneration based on the remuneration | type". 5. Anders mention that PartyType was missing a field for URLs. Typically a reference to the company's webpage may be included in the PartyType. Thomas wished that it should be possible to submit more than one URL. As a result an attribute indicating the primary URL could be added. | A simple type, HttpUrlType, that constrains anyURI to only http URLs was created as | was a type named WebAddressType. The latter contains an optional Name element to | describe or name the web address and a required Url element of the new HttpUrlType. | The WebAddressType also contains an optional attribute named primary with the fixed | value primary. When listing multiple web addresses this attribute should be used to | indicate the primary web address. | | The PartyType type was extended with an element WebSite of type WebAddressType that | can occur zero or more times. Only one of which should be marked primary="primary". | | | The Company Web Site | http://www.thecompanywebsite.com/ | | | http://www.someotherwebsite.com/ | 6. The swedish description of InsurancepolicyId mentions that it must be supplied. We do not explicitly mention other required elements so this text should be removed in order for our documentation to be consistent. | The text "Försäkringsid måste anges" was removed from the documentation for | InsurancePolicyId. 2013-04-24 On-line conference to finalise xml4sak -------------------------------------------------- 1. A proposition to add a type attribute denoting the issuing country for identity numbers was accepted. We decided to include this optional attribute on the OrganisationNumber and PersonNumber elements in the PartyType. We also decided that the values should denote issuing countries using ISO 3166-1 alpha-2 country codes. | In order to add an attibute a new type needed to be created. I added the type | NationalIdentificationNumberType which implements a simple type of type token and | extends it with the optional attribute issuer. Both OrganisationNumber and | PersonNumber are updated to use this type instead of token. The description for issuer | is as follows: | [en-gb] Issuer: The country code of the issuing country using ISO 3166-1 alpha-2. | [sv-se] Utfärdare: Landskoden för det utfärdande landet uttryckt som ISO 3166-1 | alpha-2. | | There are no restrictions on the type forcing it to be exactly two characters so it is | possible to supply an issuer that is not a country code. I thought of restricting this | using a regex but decided that it might be better to allow exceptions from the country | code rule in order to allow for instances where a country may have more than one | issuing authority. 2. Since not all countries use national identification numbers, in fact in Germany it is illegal to use the various tax numbers, social security numbers and so on for anything other than their intended use by the issuing entity, we decided to make both OrganisationNumber and PersonNumber optional. We extended the definitions of the Choice group so that at least one value (number or name) must be supplied. | Changed the definitions within the Choice group so that sequences not requiring | PersonNumber or OrganisationNumber exists and that all defined sequences require at | least one value. 3. We discussed whether we should change the more complex solution of using a predefined enumeration in union with a token to implement open lists, with a regex pattern based implementation which would make the schema easier to read. After experimenting with the two alternatives we decided to retain the union-based solutions since this gives intellisense and validation whereas the pattern-based solution only gives validation. 4. We decided that the first predefined premiumtype would be called remunerated and refers to the definition proposed in G1. | Added an annotation/documentation to the value remunerated in the list. 5. We made several changes to the annotations for GrossPremium, NetPremium, Surcharge and Tax in order to fit with the new premium structure proposed in the 2013-04-11 meeting. | I updated the annotations for the elements according to the decision from the meeting. | The previous descriptions are retained as annotations but are tagged with | source="remuneration" to signify that they are valid for the premiums tagged with | type="remuneration". 6. We decided to change the cardinality for the Premium element in InsurancePolicyType from 1:1 to 0:n. The motivation behind this is that there may be applications where we want to confer that an insurance exists without disclosing it's cost. We may also want to supply multiple premium types. | Changed minOccurs to zero and maxOccurs to unbounded for Premum in the | InsurancePolicyType definition. 7. We decided to extend the allowed protocols for the HttpUrlType to allow both http and https. We agreed that a restriction to http/https was acceptable. | Added a regex pattern that allows for https to the previous pattern that allows http. 8. We decided to include annotations for the values of enumerations as well. | The values for the enumerations PhoneNumberTypeType, PremiumPeriodicityType and | SurchargeTypeType have all been updated with annotations. Except for premium type | transaction since I am unsure of the meaning and how it differs from the other premium | types. 9. Miscellaneous changes | I fixed a few spelling errors annotations. | I rearranged the order of types and elements so that they would be arranged | alphabetically within their section. 2013-04-24 Follow-up on issues discovered when implementing changes from 2013-04-24 ------------------------------------------------------------------------------------ 1. Extended the definition of persons within PartyType to allow for an element called FullName. This is necessary since som entities have legacy systems where first and last name are not separate values and it is not clear where to separate the two. | The choice sequences for persons was extended with FullName. Currently there are three | representations for a person allowed. | PersonNumber required but remining elements optional | No PersonNumber given, LastName required but remaining elements optional | Only FullName required, no additional elements defined. 2. The attribute names for Content-Type and FileExtension does not follow our agreed upon naming standard. | The attribute names were changed to contenttype and fileextension. 2013-05-08 On-line conference to finalise xml4sak -------------------------------------------------- 1. We decided to add the optional element TransactionId to the header. | Implemented TransactionId as a global element in Xml4Sak-messaging of type Token and | included it in the Header structure allowing zero or one occurance. 2. We decided to introduce a miscellanous type to allow for content unspecified in the Xml4Sak standard. The contents of this type will zero or more of Any element but with the restrictions that it can not be an element from the Xml4Sak namespace and that it must be validated, i.e. qualified by a namespace. We agreed that the name should be AgreedSupplement rather than Miscellaneous to signify that this extension should be agreed upon by both parties in the information exchange. | Implemented the type AgreedSupplementType that contains Any element zero or more times. | The elements must not be in the Xml4Sak namespace (namespace="##other") but must be | defined by a namespace so that they can be validated (processContents="strict"). | Implemented the global element AgreedSupplement of type AgreedSupplementType. We decided to allow this new element zero or more times for Header, InsurancePolicy, Party and Document. | Added a reference to the AgreedSupplement element in HeaderType in Xml4Sak-messaging | and in DocumentType, InsurancePolicyType and PartyType in Xml4Sak-basetypes. 3. We decided that the Xml4Sak standard now is release ready and finalized the standard with Release Candidate status. 2013-05-22 Addressing documentation issue ------------------------------------------ 1. A change to PartyType that will allow parties with only LegalName and no OrganisationNumber, just FirstName,LastName and no PersonNumber or only FullName with no distinction regarding FirstName and LastName was implemented to give greater flexibility. | The various permitted combinations have been changed from | (OrganisationNumber [, LegalName]) | (PersonNumber [, FirstName, LastName]) | to | (OrganisationNumber [, LegalName]) | (LegalName) | | (PersonNumber [, FirstName, LastName, FullName]) | | ([FirstName,] LastName [, FullName]) | (FullName) 2. The above change created some issues regarding documentation and ambiguity. In order to avoid this the elements OrganisationNumber, LegalName, PersonNumber, FirstName, LastName and Fullname are to be changed into global elements in basetypes. | The elements OrganisationNumber, LegalName, PersonNumber, FirstName, LastName and | FullName have all been moved to the global scope. | Since the elements changed context and scope the description needed to be changed from | definite article, "The organisation number identifying the company", to indefinite | article "The organisation number identifying a company". This change of article has | been applied to all elements that changed scope. 2013-05-27 Updating missing documentation ------------------------------------------ 1. The documentation for PercentageOfGross, PercentageOnNet, Fee and Term (SurchargeType) did not follow the agreed upon pattern of "name: description" missing the name part. This has been rectified by adding the "name:" to the descriptions. 2013-05-30 Removing anonymous type ----------------------------------- 1. The Start and End elements within PeriodType contained identical anonymous types. Since we have decided against anonymous types these were refactored into a named type by the name of BoundedDateTimeType. 2013-06-14 Added lastUpdated to InsurancePolicy ------------------------------------------------ 1. The Xml4Sak standard has been approved by the Steering Committee on June 10 2013 with the addition of a time stamp to indicate when the Insurance Policy was last updated. | In order to incorporate the new requirement in the finalised standard an optional | attribute was added to the abstract basetype InsurancePolicyType. | | | | 2013-12-13 Corrective update to Xml4Sak version 2.0 ---------------------------------------------------- 1. A reviewer commented that the regular expression used to validate the email in EmailType uses non-capturing groups which aren’t supported by Xml schemas. | The regular expression is rewritten so that it doesn’t use a non-capturing group. The | new regex also allows international characters. 2. We missed an element that designates the current status of the insurance. A change request with reference number 40668 was registered in Hubbus. This change request has been approved by the SFM Steering Committee for Xml4Sak and set to be included in this update. | Added to the abstract | InsurancePolicy base type as well as the global element Status and the two types | StatusType which defines the status type and StatusCodeType which is an enumeration of | valid status codes. 3. We also missed to include an optional element for the annulment date. A change request to include this was registered in Hubbus with reference number 40925. This change request has been approved by the SFM Steering Committee for Xml4Sak and set to be included in this update. | Added the global element CancellationDate to the base schema and added a reference to | it from the abstract InsurancePolicy base type. 4. Finally we lack an element to signal what type of event triggered a change in an insurance policy. No change request has been registered but the SFM Steering Committee for Xml4Sak approved this addition to the standard. | Added the types ChangeEventType and EventType. The former defines the type used by the | new global element ChangeEvent and the latter is an enumeration of valid event types. | Added a reference to the ChangeEvent element from the abstract type InsurancePolicy. Since no one is using Xml4Sak version 2.0 yet I took the liberty to implement these changes as breaking changes by inserting the new elements interleaved with existing elements rather than appending them at the end.