IATA NDC Phase 1 Schema Architecture and Clarifications
Upcoming SlideShare
Loading in...5
×
 

IATA NDC Phase 1 Schema Architecture and Clarifications

on

  • 616 views

IATA NDC 1.0 Progress and Clarifications

IATA NDC 1.0 Progress and Clarifications

Statistics

Views

Total Views
616
Views on SlideShare
616
Embed Views
0

Actions

Likes
1
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

IATA NDC Phase 1 Schema Architecture and Clarifications IATA NDC Phase 1 Schema Architecture and Clarifications Presentation Transcript

  • 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 Encoding ACTIONED
  • 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 > 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 > 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 > 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 > 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 > 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
  • 27 > NDC SCHEMA SPECIFIC COMMENTS & FEEDBACK
  • 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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
  • 39 > PADIS/ DDSCC (P. Heilig, TravelPort) • Inflight Meal Codes > Recommend using PADIS code list 7161 • Actioned > Updated annotation to reference PADIS Code List 7161 NDC 1.0 Reviewer Feedback NDC Code Lists – PADIS 7161 - Actioned
  • 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 > 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