Ferrygateway Tech Workshop 2015-09-15--16
Created 21st September by Hans Björkborg.
Participants
Jan Helin – Viking Line
Robert Kaev – Tallink
Michel de Bellefon – Brittany Ferries
Jimmy Barath – Stena Line
Jorge Barbosa – Color Line (only 15th)
Brian Short – Irish Ferries
Thor Burchard – DFDS
Chris Self – P&O Ferries
Simon Ashberry – Entee
Laurence Beales – Entee
Ian Tory – Entee
Hans Björkborg - Ferrygateway
Introduction
The agenda
 Introduction and special welcome to Brian Short
o Practical things like coffee breaks & lunch
o Dinner tonight at Sjöbaren Lorensberg 19:30
 Catch-up of what has happened since last workshop
 Review of all use cases and the xml examples (published on Basecamp)
 Discussion and decision about eventual changes of the standard (some
suggestions on Basecamp)
 Error messages review and decision about principles and contents
 Configuration management
 Documentation of Ferrygateway
 Any other business
Catch-up
Hans made a brief presentation on what had happen since the last workshop in the end
of April.
Review of use-cases and xml examples
Below are some comments, actions and decisions that came across when the use-cases
were presented. The notes may not cover the full discussion and may even describe the
comments incorrectly, but will be rectified following everybody’s review.
Use-case #2 – Crossing with car (Brian)
 Port codes
o We have used 3-characters, but it does not seem to provide uniqueness.
Suggested on Basecamp is ‘LOCODE’ which is a 5-character code (2 for
Country plus 3 for Location).
 Flag for Fastcraft does exist in the standard. Just a note.
1



Some services include other services, e.g. Club Class for Irish ferries includes
Priority boarding, which cannot be bought separately. This can be explained to
the user as an information item.
The place of the cost element was discussed. Actions were decided later.
Vehicle measurements work fine for this use-case.
Use-case #3 – Family holiday from UK to France (Michel)
 Services returned; should be included each time. This is an implementation issue,
but maybe there should be a recommendation?
 Child age
o In this use-case Michel one child is 17. However at Brittany that’s an adult.
So a warning is issued to the user that the Age category was changed to
Adult.
o The above can be handled in various ways – keep Child, but increase price
or just return an error and ask for new input. Following some discussions
in the meeting it seemed that Michel’s method was preferred. To be a
recommendation?
o Same thing could happen with a vehicle (a vehicle of 10 meters is not a
Car, but maybe a Bus).
 Get Services in Get Sailing
o Recommended options within selection criteria should be returned.
o If the user wants to have more options then the requesting system will
request that from the awarding system.
o This thing goes back to the general requirement that a returned proposal
must be bookable and should not include everything.
 Services returned
o If something is included in the price then it should be stated as ‘services
included’ rather than ‘services returned’, but only as a response from ‘get
sailing request’.
o Get services response is only for choices.
 Cabin allocation
o Allocation of people in category cabins is in the standard. However there
is a wish that it also would be for specified cabins.
o Maybe in the next release? No decision to change now.
 Group bookings including personal service
o Not now, maybe in a future release
 Travel documents
o There is a need to have a deep-link to travel document. The meeting
decided accordingly.
 What have been sold as opposed to what was requested?
o Maybe for a future release
Use-case #4 – Cruise for two persons (Robert)
 There was a discussion why we should require specific date and time and
number of sailings since the awarding system probably returns what the
operator considers being reasonable and relevant. No decision was made and
from the agent’s perspective (Entee) it is better to keep it as it is. This could be a
possible item for prioritisation.
2


Contact person for the booking can be someone that is not travelling, e.g. an
assistant. This must be possible and requires personal info like name, address,
telephone, and email.
Robert mentioned that some things need to be amended in the example code due
to misunderstanding and/or the automatically generated code.
Use-case #5 – Multi-leg same operator (Jimmy)
 A request for multi-leg will result in two bookings internally, but for the customer
it looks like just one.
 There was a question if we really need AllPets, AllPassengers and AllVehicles. The
conclusion was - Yes we do.
 Otherwise no problems, pretty much straightforward.
Use-case #6 – Short Sea crossing with Van and trailer (Chris)
 In this example there was an offer-code that the customer tried to use. Discussion
appeared where to connect this offer-code and the conclusion was to connect it
to booking level.
 Chris explained that in this case up to 400 combinations would be returned from
the reservation system.
o Both single leg and return pricing exist
o A certain return price is only valid if the customer choses a specific
outward leg.
o Ferry component can be pares if the outward and return gives a price that
is different from out + return single legs.
o Decision to add an attribute to the Ferry component element,
‘Combination rule’, not Boolean, and can have values like ‘none’, ‘use leg
set no’ or something else. Also add the attribute ‘leg set no’ as an optional.
The use of this would reduce the number of returns from the awarding
system dramatically.
Use-case #7 – Simple crossing, no complications (Thor)
 The standard worked well for this use-case. No comments.
Use-case #8 – Foot passengers only, simple case (Chris)
 This simple case demonstrated the functional requirement ‘quick booking’ very
clearly – get prices back and book.
 Price token was discussed, but I cannot remember any conclusions.
Use-case #9 – Change a booking (Jimmy)
 Recall the booking case.
 The description of the booked cabins should be returned. It seemed that the
description had disappeared.
 In the response it is doubtful if we really should have ‘Services requested’. It
should instead be just ‘Services’. There was a discussion whether to change this
all through the standard and to add a new attribute with values like ‘Included’,
Requested’, ‘Booked’ etc. Subject to later decision in the meeting.
Use-case #10 – Cancel a booking (Thor)
 Cost details should be added to this use-case.
 Otherwise straightforward.
3
Use-case #11 – Refresh cache (Robert)
 It was noted that PassengerSubCategory must be documented. This is provided
by the operator and should include a description.
 In the use-case Ship name & Fastcraft are to be added.
 Get routes should be as complete as possible, e.g. Route Group, Port location.
Changes to the standard
Even though the ambition was that the standard should have been very near a
completion before this workshop, it appeared that some changes must be made since
they will contribute strongly to a success and make the implementation easier. It was
therefore decided to let Entee perform the decided changes. Unfortunately this will
delay the end-date by approximately one month.
Some changes have already been covered in the use-case reviews as described above.
Below follows additional changes, of which many derives from Michel’s proposals (see
published text file, some changes already implemented in version 0.7).
Below are things that I noted (may exist in the next sub section or not)
 Search Criteria
o To be removed from responses all through the standard (?)
 Move attributes to Sailing level
o To move Pets, Pax and Vehicle to Sailing level
 Cost element
o Cannot remember the decision where to place it
o Add attributes to Cost Detail (Sailing id and Quantity)
 Field length restrictions
o Decision to have just one restriction = 256 characters
 Cost categories
o Definitions needed. Hans has emailed to all and expect their definitions
back. He will then compare and make a consolidated list.
 Success message
o We have Info, Warning, Recoverable and Fatal
o That’s it, success message not needed.
 ‘Service Requested’ to ‘Service’.
o It was decided to implement this change all through the standard.
o Entee will make a special use-case to illustrate the solution
o My interpretation is that the message flow would be something like this
 Get Sailing
 Sailing response  Included services
 Get services
 Service response  Possible services
 Price request
 Price response  Selected services
 Book
 Returned after Get Sailing
o Everything within the selection including mandatory things
Below changes were decided and are changed to next version
 Vehicle dimensions
4

















o Changed from meters to centimetres
Added default=false to LeadVehicleCodeType@IsHireCar
Changed PassengerType@Age documentation element.
o Now "Passenger age in years. Required if PassengerCategoryCodeType is
Child".
Added "Type" suffix to type declarations that don't have them.
o Changed PassengerCategoryCode to PassengerCategoryCodeType.
o Changed type names defined in external xsd's.
o Changed type attributes to be correct for name changes.
Changed SailingInfoResponseType@CheckinStartDateTime &
CheckinEndDateTime to use=optional.
Changed documentation element for CostDetailType@Amount &
CostType@GrossAmount.
o Now "Amount in the currency specified by the message Context element"
/ "Gross amount in the currency specified by the message Context
element".
Added CostDetailType@Quantity optional attribute, as unsigned int defaulted to
"1".
Added CostDetailType@SailingId optional attribute.
Changed documentation element for AllPassengers/AllPets/AllVehicles elements.
o Now "Whether element applies to all passengers. If true, the
PassengerRefs element is not required" (or similar).
Made OnBoardAccommodationServiceReturnedType@IsAccessible &
IsPetAllowed attributes optional.
Added explicit default=false to all optional boolean attributes that didn't have a
default.
o OnBoardAccommodationServiceReturnedType@IsAllergyFriendly/IsAcce
ssible/IsPetAllowed.
o GetSailingsResponseType@IsOnlyMinicruise.
o AllPassengers/AllPets/AllVehicles attributes defined in various places.
Added new abstract BookBaseResponseType, and derived BookResponseType
and RecallBookingResponseType from it.
o To give each top-level message element a unique type.
Removed Star attribute from OnBoardAccommodationServiceReturnedType.
Made Pets & Vehicles attributes optional.
o Added minOccurs=0 to all Pets & Vehicles elements declarations.
o Removed minOccurs=0 from PetsType/Pet & VehiclesType/Vehicle
declarations.
Removed OnBoardAccommodationServiceReturnedType@Star attribute.
Replaced FareDetailsResponseType/ProductDescription element with
FareDetailsResponseType@ProductDescription attribute.
Added max lengths for string values.
o Defined new type RestrictedString (string type with max 256 character
length).
o Replaced attribute type from string to RestrictedString everywhere
applicable.
Added FerryComponentBookResponseType/BookResponseLinks optional
element to allow arbitrary urls to be returned in Booking Response.
5







o Added BookResponseLinksType & BookResponseLinkType type
declarations to define schema for this.
Created new type TimetableSailingInfoResponseType for
GetTimeTablesResponse/SailingsInfos/SailingInfo.
o Extends existing SailingInfoResponseType.
o Adds optional @ShipName & @IsFastCraft.
Removed SailingGetSailingsResponseType@IsAccommodationMandatory,
because same info is returned in SailingInfoResponseType.
Removed SailingSearchCriterion element from GetSailingsResponse//Sailing.
Added optional Request element to MessageResponseType (ie for all response
messages).
Moved OfferCode from being a FareDetails attribute to a new FerryComponent
element.
o Created new OfferCodeType to hold moved attribute.
Moved Passengers/Pets/Vehicles/ContactDetails elements out of
FerryComponent elements.
Added optional attributes to ContactDetailsType.
o Title, Forename and Surname
o PassengerId
Other observations or comments
 Stateless should be documented carefully. Very important to understand this.
 Template for SLA
o Perhaps make a framework for SLA between Operator and Agent
Error messages




Each error message has a code that is fixed (number).
o The short name like ‘Route code invalid’ is fixed and the meaning of it
must be clear, but the description is free and is meant to clarify the
problem.
The request should be echoed back in the response to be able to point (xpath) to
where the problem is. However this should only be done when it is a real
problem.
There should be a recommendation on how to use the severity levels in the
documentation.
It was decided to remove the codes that are not valid or relevant to Ferrygateway
standard. Thor will do this (already done). The list is published on Basecamp and
all members should review and publish their comments on Basecamp.
Documentation
We made a review of the template. Simon has made notes of that discussion and will
pick good examples from existing similar documentations.
It was discussed whether to create a ‘black box’ test system with fixed responses – a
possible way to make the initial test easier.
The high-level functional documentation section is done, but Hans needs to go through it
again and check validity against the latest version of the standard.
6
Other documentation comments / notes
 Message flow
 Message description like Stena Line
 Examples message requests and responses
o Use-case description (Hans’ document)
o Links to the xml examples
o UML sequence diagrams
 Ferrygateway default standards (Hans’ document)
 Recommendations
o How to handle a case of Child or not (see use-case #3 above) and similar
situations, e.g. Vehicle dimensions.
o How to update the cache
o We could have one generic section and then references from example xml
use-cases.
 Stateless to be described.
Configuration management





All versions should be backwards compatible. However there will be situations
when that is not possible. Version handling will be necessary.
Major new releases will come in the future. Operators can probably handle that
more easy than agents.
Different versions will exist at the same time and agents will have to be able to
handle that (like they do today).
How to distribute the schema was discussed. Surely there must be a sourcecontrol system – something for the future technical committee to determine.
Where to host the standard was also discussed.
Next steps
The below table is already distributed.
No.
1
2
3
4
5
6
7
8
9
What
Amend/change the XSD according to
decisions on WS 15-16 Sep
Amend/change use-case xml examples to
new XSD
Report any findings to Hans
Fix the Error list – clean-up
Create first version of Technical
documentation
Conference call if needed to sort out any
issues with use-case writing
Post any issues/comments with new XSD or
use-case on Basecamp
Document the workshop 15-16 Sep. Send to
Simon for filling the gaps.
Write use-case for Error handling
Who
Entee (Ian)
When
9 Oct
Use-case
owners
Use-case
owners
Thor
Entee
(Simon)
Use-case
owners
plus Entee
All
22 Oct
Hans
22 Sep
Michel
21 Oct
Status
21 Oct
22 Oct
18 Oct
OK
9-22 Oct
9-22 Oct
OK
7
No.
10
11
What
Final technical workshop in London
- Hans to book and prepare
- Members to finalise and review
Report to the FGW General meeting that we
have a version 1.0 of Ferrygateway
Who
Hans +
team
members
Hans
When
22 Oct
9-17
Status
4 Nov
Notes written down by Hans
8