4. 4 >
NDC 1.0 Gap Analysis
BRD Requirements
• Post IATA PADIS/ DDSCC review meetings, 26 BRD items
re-classified (in Sep-07-2013 BRD Gap Analysis (v5)
spreadsheet)
5. 5 >
NDC 1.0 Gap Analysis: BRD Requirements: Functionality in Schema Explanation
Prod Offer 60: (BRD 81)
TRAVELER PREFERENCE: OVERSIZE SEATING
REQUIREMENT:
Schema should
support oversize
seating preference
qualifier in a
Shopping query.
ASSUMPTIONS:
Airlines have
backend logic that
can accommodate
an oversize seating
request, e.g.
returning two
adjacent seats or
larger-
dimensioned seats.
SCHEMA SUPPORT RQ:
NDC request schema allows specification of
special traveler needs in the SpclAttributes
element:
SCHEMA SUPPORT RS:
NDC response schema allows
oversize seating accommodation
to be described in multiple
service description elements:
Notes:
1. Both IATA and
implementer-
proprietary
encoding
supported
2. May be
specified at a
segment level.
6. 6 >
NDC 1.0 Gap Analysis: BRD Requirements: Functionality in Schema Explanation
Prod Offer 66: (BRD 87)
TRAVELER VALUATION: TRAVELER SCORE
REQUIREMENT:
Schema should
support calculated
traveler value
score in a
Shopping query.
ASSUMPTIONS:
Traveler valuation
is a backend
operation that
involves
calculating a
traveler score from
airline stored
traveler
information (e.g.
from a traveler
profile).
SCHEMA SUPPORT RQ:
NDC request schema allows specification of a
traveler profile index in the root level
ReferenceDefinitions/TravelerRefInfo/
ProfileIndex element:
SCHEMA SUPPORT RS:
NDC response schema allows
specification of a calculated traveler
score with associated calculation details:
7. 7 >
NDC 1.0 Gap Analysis: BRD Requirements: Functionality in Schema Explanation
Merchandise 2: (BRD 96)
DISCLOSURE AND MERCHANDISING DETAILS: ADDITIONAL PRODUCT QUALIFIERS
REQUIREMENT:
Schema should
support disclosure
and merchandising
details in a
Shopping query
and response.
ASSUMPTIONS:
Due to the
complexity and
change rate for
disclosure and
merchandising
details, a
structured element
is not required.
SCHEMA SUPPORT RS:
NDC response schema contains a common MediaContent element as a child element of
Services—that provides a method to specify a URL for ancillary service disclosure and
other merchandising details:
8. 8 >
NDC 1.0 Gap Analysis: BRD Requirements: Functionality in Schema Explanation
Requestor 20: (BRD 191)
AIRLINE STAFF EMPLOYEE: NON REVENUE TRAVEL STATUS
REQUIREMENT:
Schema should
support airline
employee non
revenue travel
status in a
Shopping request.
SCHEMA SUPPORT RQ/RS:
SCHEMA SUPPORT REQUEST/RESPONSE: There is an IATA Passenger Type code "AST" for
"Airline Staff Standby" that may be specified to designate an airline employee. Additionally, all
NDC ―Passenger Type‖ encoding supports IATA Passenger Type Codes as well as
implementer-proprietary passenger type codes. :
9. 9 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Requestor 9 (BRD 180): Schema should support airline nationality (country
code) in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "airline nationality."
> NOTE: Airline Designator and Airline Name supported in schema
• Requestor 11 (BRD 182): Schema should support airline prefix in a Shopping
query.
> Please provide NDC shopping schema relevancy and requirements for "airline prefix.―
> Assumption is that this would be an internal lookup based on airline designator and/or name
> NOTE: Airline Designator and Airline Name supported in schema
• Requestor 12 (BRD 183): Schema should support secondary airline prefix in a
Shopping query.
> Please provide NDC shopping schema relevancy and requirements for ―secondary airline prefix.―
> Assumption is that this would be an internal lookup based on airline designator and/or name
> NOTE: Airline Designator and Airline Name supported in schema
10. 10 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Requestor 13 (BRD 184): Schema should support secondary airline prefix in a
Shopping query.
> Please provide NDC shopping schema relevancy and requirements for ―secondary airline prefix.―
> Assumption is that this would be an internal lookup based on airline designator and/or name
> NOTE: Airline Designator and Airline Name supported in schema
• Requestor 14 (BRD 185): Schema should support airline operation type in a
Shopping response.
> Please provide NDC shopping schema relevancy and requirements for ―airline operation type."
> NOTE: Airline Designator and Airline Name supported in schema
• Requestor 15 (BRD 186): Schema should support unique internal airline ID
reference in a Shopping response.
> Please provide NDC shopping schema relevancy and requirements for "unique internal airline ID."
> NOTE: Airline Designator and Airline Name supported in schema
11. 11 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Requestor 17 (BRD 188): Schema should support airline designator for an airline
employee in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "airline designator for an airline
employee."
> NOTES:
– 1. All shopping queries support IATA passenger type codes (PTC)
– 2. A PTC indicating an airline employee may be specified (for example: AST: Airline Staff Standby)
• Requestor 18 (BRD 189): Schema should support airline employee date of hire in a
Shopping response.
> Please provide NDC shopping schema relevancy and requirements for "airline employee date of hire."
> NOTES:
– 1. All shopping queries support IATA passenger type codes (PTC)
– 2. A PTC indicating an airline employee may be specified (for example: AST: Airline Staff Standby)
• Requestor 19 (BRD 190): Schema should support airline employee non revenue travel
level in a Shopping query/ response.
> Please provide NDC shopping schema relevancy and requirements for "airline employee date of hire."
> NOTES:
– 1. All shopping queries support IATA passenger type codes (PTC)
– 2. A PTC indicating an airline employee may be specified (for example: AST: Airline Staff Standby)
12. 12 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Requestor 21 (BRD 192): Schema should support airline employee
employment status in a Shopping response.
> Please provide NDC shopping schema relevancy and requirements for "airline employee
employment status."
> NOTE: Airline Employee may be specified as a PTC in NDC shopping qualifiers
• Requestor 22 (BRD 193): Schema should support airline employee job title in
a Shopping response.
> Please provide NDC shopping schema relevancy and requirements for "airline employee job title."
> NOTE: Airline Employee may be specified as a PTC in NDC shopping qualifiers
• Requestor 59 (BRD 230): Schema should support booking channel/ requestor
telephone city access code in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "city code type."
> NOTE: (IATA) city code and a city name are supported in NDC point of sale information
13. 13 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Requestor 62 (BRD 233): Schema should support booking channel/ requestor
city code type in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "city code type."
> NOTE: (IATA) city code and a city name are supported in NDC point of sale information
• Requestor 66 (BRD 237): Schema should support booking channel/ requestor
telephone country access code in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for ―telephone country access
code."
> NOTE: ISO country code, country name and ICAO country code are supported in NDC
point of sale information
• Requestor 67 (BRD 238): Schema should support booking channel/ requestor
alternate country name in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "country alternate name."
> NOTE: ISO country code, country name and ICAO country code are supported in NDC
point of sale information
14. 14 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Requestor 70 (BRD 241): Schema should support booking channel/ requestor
country added to ICAO/ ISO list date in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "country added to ICAO/ ISO
list date."
> NOTE: ISO country code, country name and IACO country code are supported in NDC
point of sale information
• Requestor 71 (BRD 242): Schema should support booking channel/ requestor
country deleted from IACO/ ISO list date in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for " country added to ICAO/ ISO
list date."
> NOTE: ISO country code, country name and IACO country code are supported in NDC
point of sale information
• Requestor 73 (BRD 244): Schema should support booking channel/ requestor
country name source in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "country name source."
> NOTE: ISO country code, country name and ICAO country code are supported in NDC
point of sale information
15. 15 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Requestor 75 (BRD 246): Schema should support booking channel/ requestor
country check digit specific data in a Shopping query.
> Please provide NDC shopping schema relevancy and requirements for "country check digit."
> NOTE: ISO country code, country name and IACO country code are supported in NDC
point of sale information
• Requestor 86 (BRD 257): Schema should support traveler spoken language in
a Shopping query.
> Please confirm if the @PrimaryLangID and @AltLangID attributes in the common
PayloadStdAttributes (in each NDC RQ/RS schema) solve this requirement.
> If it does not, please provide additional requirement detail.
• Requestor 100 (BRD 271): Schema should support travel agency IATA status
in a Shopping response.
> Please provide NDC shopping schema relevancy and requirements for "travel agency status."
> NOTE: Agency ID, Pseudo City Code, User ID, User Role, User Password, ARC Number,
Duty Code, SINE, LNIATA and ERSP are supported in NDC point of sale information
16. 16 >
NDC 1.0 Gap Analysis: BRD Requirements
Additional Detail Required
• Prod 58 (BRD 79): Schema should support traveler preference-based other
preferences (e.g. "only in wide body aircrafts", "Chinese speaking staff
preferred", "need duty free shop at connecting airport", "only offers that are
valid for at least one week") in a Shopping query.
> Please provide individual requirements for this collection of requirements.
17. 17 >
NDC 1.0 Gap Analysis: BRD Requirements
No Action – Profile Related
• These requirements specifically mention ―profile‖
• Understanding is Profile and Booking requirements
still to be specified and are out of scope for NDC
Shopping/Pricing schema
> Requestor 77 (BRD 248): Customer Profile: Form Of Payment
> Requestor 78 (BRD 249): Customer Profile: Form Of Payment:
Preference Rank
> Requestor 79 (BRD 250): Customer Profile: Form Of Payment:
Type
18. 18 >
COMMENTS & FEEDBACK
NDC PILOT
AND
PADIS/ DDCSS REVIEWERS
20. 20 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• Will NDC messages use
PADIS codes where ones
exist, such as error codes?
• Actioned
> Common NDC response
message ForInfo/Text,
InfoGroupType/Error/Code and
InfoGroupType/Error/Text
annotations updated with:
– Status Messages: Where possible, it
is recommended that PADIS
Processing Status Encoding be used.
– Error Messages: For maximum
interoperability, it is recommended
that PADIS Error Encoding be used.
NDC 1.0 Reviewer Feedback
PADIS Error & Response Encoding
ACTIONED
21. 21 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• Why is it that many indicator type attributes are of
ChoiceType rather than Boolean when a number of them
should only be true or false and there is no need to open it
up to other options?
• Answered: Explained on September 3 PADIS/ DDSCC Call
> ChoiceType is a simple type that is a union between an enumerated list
(with ―Y‖ and ―N‖ values) and an xsd:string. Using this simple type
consistently in the schema:
– Provides a consistent simple type pattern for choice properties
– Allows implementers to define unique choice values that may indicate a
stronger preference than yes or no, such as "preferred"
– Satisfies multiple BRD requirements for qualifier preference levels
NDC 1.0 Reviewer Feedback
Use of ChoiceType vs. xsd:boolean
ANSWERED
22. 22 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• I remember that we had discussed seats as a qualifier for
making shopping requests – such as I want flights with
economy comfort seats, etc., not a request for seat maps,
hence why is it included?
• Answered: Explained on September 3 PADIS/ DDSCC Call
• The NDC SeatAvailability message pair supports a key optional
service—premium seats—and includes premium seat qualifiers
> The OpenAxis SeatAvailability schema already included seat map
– Seat map used in combination with premium seat qualifiers as an
effective part of the NDC airline branding/ differentiation requirements
– No requirements were submitted to remove existing seat map
functionality from OpenAxis schema
– All seat map-related schema functionality is optional
NDC 1.0 Reviewer Feedback
SeatAvailability in NDC Schema Suite
ANSWERED
23. 23 >
PADIS/ DDSCC (S. Livezey, Sabre)
• In the release notes, many of the messages include the following statement
- "The message also returns multi-media content at message level...". This
appears to contradict the non-functional requirement (BRD section 8)
stating that "Attachments must not appear in the message – only links to
them". Do the messages, indeed, include elements with embedded media
content? If so, these need to be changed to URL/URI references?
• Answered: Explained on September 3 PADIS/ DDSCC Call
• The NDC root-level MediaContent common element contains the message
wide collection of images and/ or media links
> Images are represented as xsd:string-based image ID‘s
> Links to media content are represented as xsd:anyURI URL links
• A combination of service-level properties distinguish multiple airlines that
may be returning media with the same optional service encoding
> Service/@Airline: Service provider designator
> Service-level MediaReference element with @ItemID and @LinkID
NDC 1.0 Reviewer Feedback
Multimedia Content in NDC Messages
ANSWERED
24. 24 >
PADIS/ DDSCC (S. Livezey, Sabre)
• None of the NDC schemas are assigned to a target
namespace. I believe this deviates from existing IATA
standards and causes all schemas to be treated as
chameleons?
• Answered: Explained on September 3 PADIS/ DDSCC Call
> At the time this comment was received, an NDC namespacing strategy
was being created.
> A formal NDC namespacing strategy has yet to be finalized
> Added to NDC 1.0 Message RQ/RS schema
– xmlns="http://www.iata.org/NDC/ShoppingPricing/2013/09/1.0"
– targetNamespace="http://www.iata.org/NDC/ShoppingPricing/2013/09/1.0"
> Added to NDC 1.0 Common schema
– xmlns:ns="http://www.iata.org/NDC/ShoppingPricing/common/2013/09/1.0"
NDC 1.0 Reviewer Feedback
NDC Schema Namespacing
ANSWERED
25. 25 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• Why are there references to other (non-air) segments in the
schema, e.g. ―OtherSegmentType‖?
• Answered: Explained on September 3 PADIS/ DDSCC Call
NDC 1.0 Reviewer Feedback
NDC ―Non-Air Segment‖ Reference
Airlines may have bilateral agreements with other (non-
air) suppliers via frequent guest programs that are
supported as shopping qualifiers in NDC Fare Search,
Flight Price and Service Price messages
PADIS 9972 Originator Type Code values are supported
in Point of Sale
(SaleInfo/Identification/RequestorInfo/@RequestorType)
ANSWERED
26. 26 >
PADIS/ DDSCC (S. Livezey, Sabre)
• In several schemas there are cases of large and complex anonymous types that are
defined in message specific schemas (e.g. "Flight" and "Segment" elements defined in
the FareSearchRS schema). This greatly reduces the amount of type reuse in
application and service provider code, as well as the interoperability between NDC
messages.
• Answered: Explained on September 3 PADIS/ DDSCC Call
> The quantity of anonymous types have been substantially reduced via
references to global elements in the CommonTypes schema—which were
updated when the final NDC AirShopping schema was done.
> To meet the goal of an enforced NDC vocabulary within the schema
– Where possible, the same element name is consistently used in multiple
schema
– Where there are differences in the elements due to schema intended
functionality (e.g. child elements, element cardinality, etc.), one of the
element corresponding base types will be used versus a reference
– Examples:
» AirlineOperatorIDType, AirlineOperatorCoreType, AirlineOperatorDetailType
» BundleContent (uniform representation, reference to global element)
NDC 1.0 Reviewer Feedback
Anonymous Types in NDC Schema
ANSWERED
28. 28 >
PADIS/ DDSCC (P. Heilig, TravelPort)
•CommonTypes/SaleInfoType/
RequestTime
> The annotation has a ‗Note: If
time zone is not identified the
time…‘ however, the
TimeZone attribute is
mandatory so this note does
not make sense. I think
TimeZone should be changed
to optional.
> Actioned
– SaleInfoType/RequestTime/
@TimeZone cardinality
changed to optional
NDC 1.0 Reviewer Feedback
Common/Simple Types Schema - Actioned
29. 29 >
NDC 1.0 Reviewer Feedback
Common/Simple Types Schema - Actioned
PADIS/ DDSCC (R. Gill, Air New Zealand)
•SimpleTypes
> Suggest to add ―test‖ attribute.
This is to allow test data to be
sent in the request during the
development and testing phases.
For us it is normally the name of
the stub message to be used for
the response.
> Actioned
– @TargetSystem and
@TargetSystemName added to
PayloadStdAttributes
30. 30 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• TravelerInfo/@Type and
TravelerIDs/@PaxType
> Why is Pax type mandatory
multiple times within a schema
in some NDC messages?
> Actioned
– Redundant, mandatory
TravelerInfo removed from
NDC schema
– FareSearchRQ
– FlightPriceRQ
– ServiceListRQ
NDC 1.0 Reviewer Feedback
Multiple Schema - Actioned
31. 31 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• FlightPriceRQ/OriginDestination/Flight/Equipment
> I find it strange that Equipment would be mandatory – if this request is for a
specific flight, surely the airline knows what the equipment is and the seller
should not have to send this. (it is not mandatory in ServicePriceRQ)
– Actioned FlightPriceRQ/ OriginDestination/Flight/ Equipment
minOcc changed to 0 (optional)
NDC 1.0 Reviewer Feedback
FlightPrice Schema - Actioned
32. 32 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• FlightPriceRQ/OriginDestination/Flight/Departure/@Time
• FlightPriceRQ/OriginDestination/Flight/Arrival/@Time
> This is also mandatory – no need to send as airline knows the
time – change to optional
– Open: PADIS/ DDSCC review/ feedback requested
NDC 1.0 Reviewer Feedback
FlightPrice Schema - Open
33. 33 >
PADIS/ DDSCC (R. Gill, Air New Zealand)
• SeatAvailabilityRQ
> Suggest to add ―OptionalServices‖ element from response
schema. Reason: This is to allow us to send details of products
that have already been purchased.
– Open: PADIS/ DDSCC review/ feedback requested
> Due to US DOT 302 we need to have the ability to provide price
relating to a particular date. Propose adding AltTicketingDate
structure
– Open: PADIS/ DDSCC review/ feedback requested
NDC 1.0 Reviewer Feedback
SeatAvailability Schema - Open
34. 34 >
NDC 1.0 Reviewer Feedback
ServiceList Schema - Actioned
PADIS/ DDSCC (P. Heilig, TravelPort)
• ServiceListRQ/
OriginDestination/
Flight/ActionCode
> Should not be mandatory
since these messages are
to be used pre-booking
when you do not have an
action code. change to
optional.
> Actioned
– ActionCode minOcc
changed to 0
(optional)
35. 35 >
NDC 1.0 Reviewer Feedback
ServiceList Schema - Open
PADIS/ DDSCC (P. Heilig, TravelPort)
• ServiceListRQ/OriginDestination/Flight/Departure/@Time
• ServiceListRQ/OriginDestination/Flight/Arrival/@Time
> This is also mandatory – no need to send as airline knows the
time – change to optional
– Open: PADIS/ DDSCC review/ feedback requested
36. 36 >
NDC 1.0 Reviewer Feedback
ServicePrice Schema - Actioned
PADIS/ DDSCC (P. Heilig, TravelPort)
• ServicePriceRQ/OriginDestination/
Flight/ActionCode
> I find it strange that there is a
PricingRequest element with 1
occurrence and then a
PricingRequests element with a child
PricingRequest element with
unlimited occurrences. The only
difference between the two
PriceRequest elements is that one
has a choice between Service and
Seat and the other doesn‘t. should
one of these be removed?
> Actioned
– Erroneous
<PricingRequests> element
removed from schema
37. 37 >
NDC 1.0 Reviewer Feedback
ServicePrice Schema - Open
PADIS/ DDSCC (P. Heilig, TravelPort)
• ServicePriceRQ/OriginDestination/Flight/Departure/@Time
• ServicePriceRQ/OriginDestination/Flight/Arrival/@Time
> This is also mandatory – no need to send as airline knows the
time – change to optional
– Open: PADIS/ DDSCC review/ feedback requested
38. 38 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• Service Reason Code
(Service/@ReasonCode)
> Recommend using
subset of PADIS code
list 4183
• Actioned
> Updated annotation to
reference PADIS Code List
4183
> PADIS 4183 Special Condition
Codes list. Note: Reference
ATPCO assigned code for
optional services fees when
used as reason for issuance
sub code as defined in
resolution 722f, glossary in
attachment A.
NDC 1.0 Reviewer Feedback
NDC Code Lists - PADIS 4183 - Actioned
40. 40 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• Aggregator Type
> Recommend using
subset of PADIS
code list 9872
• Actioned
> Updated annotation to
reference PADIS Code
List 9872
NDC 1.0 Reviewer Feedback
NDC Code Lists – 9872 - Actioned
41. 41 >
PADIS/ DDSCC (P. Heilig, TravelPort)
• Coupon status code – recommend using subset of
PADIS code list 4405
>CouponStatusListType removed from
NDC Shopping/Pricing schema
– Relevant to ticketing/ booking
– Will use recommended code list at that time
NDC 1.0 Reviewer Feedback
NDC Code Lists – 4405 - Actioned
