iata ndc phase 1 schema architecture and clarifications

ISSUE CLARIFICATION

IATA NDC 1.0 SHOPPING/ PRICING

Distribution Data Exchange Workgroup

September 7, 2013

2 >

TOPICS

• Gap Analysis• Schema Re-Architecture• NDC Pilot and PADIS/ DDCSS Reviewer Comments

NDC BRD GAP CLOSURE CLARIFICATION

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 >

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 >


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 >


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 >


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 >

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 >



• 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 >


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:


• 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:


12 >



• 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 >



• 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 >



• 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


15 >



• 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


• 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 >



• 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 >


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 >

COMMENTS & FEEDBACK

NDC PILOT AND

PADIS/ DDCSS REVIEWERS

19 >

NDC GENERAL(Non-Schema Specific)

COMMENTS & FEEDBACK

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 EncodingACTIONED

21 >


• 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


Use of ChoiceType vs. xsd:booleanANSWERED

22 >


• 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


SeatAvailability in NDC Schema SuiteANSWERED

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


Multimedia Content in NDC MessagesANSWERED

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 Schema NamespacingANSWERED

25 >


• Why are there references to other (non-air) segments in the schema, e.g. “OtherSegmentType”?

• Answered: Explained on September 3 PADIS/ DDSCC Call


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 >

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)


Anonymous Types in NDC SchemaANSWERED

27 >

NDC SCHEMA SPECIFIC

COMMENTS & FEEDBACK

28 >


•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


Common/Simple Types Schema - Actioned

29 >


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 >


• 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


Multiple Schema - Actioned

X

31 >


• 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)


FlightPrice Schema - Actioned

32 >


• 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


FlightPrice Schema - Open

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


SeatAvailability Schema - Open

34 >


ServiceList Schema - Actioned


• 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 >


ServiceList Schema - Open


• ServiceListRQ/OriginDestination/Flight/Departure/@Time• ServiceListRQ/OriginDestination/Flight/Arrival/@Time


36 >


ServicePrice Schema - Actioned


• 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 X

37 >


ServicePrice Schema - Open


• ServicePriceRQ/OriginDestination/Flight/Departure/@Time• ServicePriceRQ/OriginDestination/Flight/Arrival/@Time


38 >


• 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 Code Lists - PADIS 4183 - Actioned

39 >


• Inflight Meal Codes> Recommend using

PADIS code list 7161




NDC Code Lists – PADIS 7161 - Actioned

40 >


• Aggregator Type> Recommend using

subset of PADIS code list 9872




NDC Code Lists – 9872 - Actioned

41 >


• 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 Code Lists – 4405 - Actioned

iata ndc phase 1 schema architecture and clarifications

Technology

schema requestor

ndc response schema

ndc request schema

ndc shopping schema

schema support rs

schema support requestresponse

schema support rqrs

airline employee