The « Market Place » project makes it possible to open the Cdiscount website to other sellers than Cdiscount.

The object of this document is to describe the format of package expected to begin the workflow of offers data integration. This format of file can be subjected directly by the client through Web service or generated from another format of file (Excel or csv…). It is the single format pivot accepted by the workflow.


Open XML Format: overall description

General information

The format of the expected file is Open XML type. It is a compressed file ti the format ZIP which contains a whole of repertories & files describing the document (XML, images .jpg) (XML, .jpg images).

Open XML: format description

Source: Wikipedia

General principle

The Office Open XML format uses a structure respecting Open Packaging Convention and defining in a simple and logic way the internal structure of all Open Office XML documents. According to this convention, the documents are ZIP files from which the various elements composing it, called parts, are connected by logical relations. The use of the ZIP allows in addition to compressing the documents, to store the data in a completely independent way in a segmented architecture.

Besides this architecture makes it possible more effectively to protect the Open Office XML documents vis-a-vis corruption from the data (if an element is damaged, the others will not be affected).

« Package » concept

The package defines the Zip archive including XML document data.

« Part » concept

A part is an element of the Zip file: a compressed file integrated into the structure of the Zip file. There are 3 types:

  • contents,
  • relations,
  • Types of contents.

Contents parts are made up of the document data. They are either with XML format or with binary format (GIF, JPEG, objects OLE,…).

The relations parts contain an XML structure defined in ECMA-376 standard reference schemes.

« Relationship » and « Relationship Part» concepts

Relationship parts specify the links between the package or a source part and a target part.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<Relationships xmlns="">

<Relationship Id="rId3" Type="http://schemas.../metadata/core-properties" Target="docProps/core.xml" />

<Relationship Id="rId2" Type="http://schemas.../metadata/thumbnail" Target="docProps/thumbnail.jpeg" />

<Relationship Id="rId1" Type="http://schemas.../officeDocument" Target="word/document.xml" />

<Relationship Id="rId4" Type="http://schemas.../extended-properties" Target="docProps/app.xml" />



A relationship has a relationship type specifying the nature of the pointed part, and the URI relating to the targeted part.

The relationship parts have a name, represented by a URI, which must respect a particular naming convention. This syntax stipulated in the standard is the following: <hierarchic path >/_rels/<source part name>.rels.


  • the package Relationship part does not have a source part, since this one is located at the root even of the document (and is obligatory), its syntax is unique : /_rels/.rels
  • the relationship part of content main part of a WordprocessingML document has the following URI: ‘/word/document.xml’, consequently the part of relation associated (which will allow for example, with the contents to target an image inserted in the document) must have the following URI: /word/_rels/document.xml.rels


Content types parts

This obligatory part has unique name: [Content_Types].xml

This name is not compatible with URI syntax: this is a technical choice. Here is an example of the content of the content type part:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<Types xmlns="">

<Override PartName="/ppt/slides/slide5.xml"

ContentType="application/vnd.openxmlformats-officedocument.presentationml.slide+xml" />

<Default Extension="png" ContentType="image/png" />

<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml" />

<Default Extension="xml" ContentType="application/xml" />




This type definition defines two extension types, the default one that specifies that all elements having the mentioned extension are of the defined type, and the other that overloads the extension defined by default stipulating a specific type for a specific part.

All contents type must be compatibles with RFC 2616(taking into account packing model rules, the support of parameters of content type is forbidden).


Open XML Format adapted to the Marketplace

Products import file

The name given to the Zip package has no importance. There is no specific norm.

The offers Zip package content is the following:

Title Type Description
_rels File
.rels xml file
Content File
Products.xml xml file
[Content_Types].xml xml file



.rels file Structure

<?xml version="1.0" encoding="utf-8"?>

<Relationships xmlns="">

<Relationship Type=""

Target="/Content/Products.xml" Id="Raa033fe51c984c6f" />


The Id attribute can contain a unique value (but it is not an obligation).

In fact, a checksum is calculated every time you import a package. this checksum is calculated depending on data included in the package (whichwhich prevents a seller to submit the same package 2 times consecutively). However, if this Id is unique every time there is a generation, then the checksum will be different.

The seller can therefore put in this attribute the value of his choice.


Products.xml file structure

Detailed Structure

The detailed structure of the Products.Xml file is described in Products.xml files

Product Package Submission error codes

The detailled page of products package submission error codes is described in Product integration